Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2011/ch4 4i js

2011-10-21T01:48:39Z

Sgade: /* See also */

== Introduction ==
This Wiki article surveys the various tools that were built to enable CRC card design on a computer. The tools cover both the tools that were developed for commercial purposes as well as the ones that were designed for educational purposes to teach Object Oriented Design.

== CRC CARDS ==
Classes, Responsibilities, and Collaborations [http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card (CRC)] is a design method focused on creating highly cohesive and modular systems. Classes represent the real world entities. They have responsibilities – data and actions the class has to support. These responsibilities can be filled by the class itself or may collaborate with other classes to fulfill it.
CRC cards are 3X5 index cards one for each class. Each has a name and has two columns one for responsibilities and one for collaborators. We can write attributes and description on back of the card.
CRC cards help visualize the design and design can be easily modified by just replacing few cards. These can be useful throughout the life cycle and provides a basis for formal analysis and design methodologies. <ref> [http://books.google.com/books/about/Using_CRC_Cards.html?id=baopCOstm_kC Using CRC Cards: An Informal Approach to Object-Oriented Development]
</ref>

=== Creating CRC Cards ===

CRC Cards help in getting the design right. CRC cards are generated as follows:
1. Discover Classes
2. Determine Responsibilities of each class
3. Describe relationship among each class.

'''Discover Classes:'''The nouns in requirement document translate to classes. We enforce certain rules while choosing classes. Identified Class is a singular noun or one that does not have functionality as some other class or is not simply a primitive type.

'''Determine Responsibilities:''' Responsibilities are the things that class knows or can do. Verbs in requirements document translate to responsibilities.

'''Describe Collaborators:''' Class might need other classes to fulfill certain responsibilities. Those classes can be identified as the collaborators for this class.

{|
|[[File:crccardlayout.jpg|x150px]]
|[[File:CRCCard.jpg|x150px]]
|} <ref>[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2007/wiki2_5_as CRC Card Layout] </ref>

 
The above CRC card describes the class Shopping Cart. A shopping cart must be able to add items and remove items form it so they become responsibilities of that class. It has to collaborate with Product Catalog to add and remove items so Product Catalog becomes collaborator to Shopping Cart

=== Disadvantages of Paper CRC cards ===
*Modification of data in hand written cards is difficult.
*The information on cards needs to be transferred into an electronic medium in order to be used by software development tools.
*As the size of the project grows it’s difficult to maintain CRC cards.
*Difficult to communicate between teams.
*Time consuming.

=== Advantages of a CRC card tool ===
*Easy to maintain cards even as project grows in size.
*It can graphically illustrate relationship between cards.
*New cards can be defined for undefined super classes, subclasses etc.
*Information can be easily entered, updated, deleted.
*Information can be verified easily.
*When renaming a card information on other cards is easily updated.
*Easy to communicate these electronic cards between teams

==CRC Card Tools==

=== Quick CRC ===

QuickCRC <ref> [http://www.excelsoftware.com/quickcrcintro.html QuickCRC]</ref> is a commercial tool developed by Excel Software for designing object-oriented software. It can be used on Mac OS X or Windows.The process of designing a program using QuickCRC involves creating a card for each class, establishing relationships, assigning responsibilities and attributes, defining and simulating scenarios, checking the model for errors and illustrating interesting relationships between objects.

[[File:quickcrc.jpg|center|x300px|Quick CRC Tool]]

A few features supported by this tool are:
*Super and subclasses can be added by selecting from a pop up list of existing cards or by typing the name.
*Provides namespace support for partitioning the cards into different functional areas which can be used while listing specifications, printing cards or exporting information to other tools.
*It can generate the inheritance graphs form the information on the CRC cards.
*Linking cards and scenarios to foreign documents is made easy and thus they can be easily accessed with a single click of the mouse.
*Allows the creation and simulation of scenarios which allows the early identification and correction of bugs.
*The designer can show the attribute access of each card responsibility. QuickCRC automatically graphs the attribute access to highlight attribute usage and incomplete areas of the design and thus allows in locating design problems.
*Information can be imported from other development tools and thus we can generate CRC cards from source code with WinTranslator or MacTranslator.
*Information can be exported to other development tools as the CRC cards can be exported to MacA&D, WinA&D or QuickUML to auto-generate UML class diagrams.
*It can generate a text or HTML coding specification, generate cards, attributes and responsibilities from selected words in a text file or selectively print CRC cards for a peer review. Design work is saved as an XML file.

=== ECoDE (Ectropic Collaborative Design Environment) ===

The Ectropic Collaborative Design Environment, ECoDE<ref>
[http://www.cc.gatech.edu/ectropic/papers ECoDE] K. A. Gray, M. Guzdial, and S. Rugaber. Extending
CRC cards into a complete design process. Technical
report, College of Computing, Georgia Institute of
Technology, Atlanta, GA, 2002. </ref>, is a development tool designed to capture two key components of Ectropic design: Collaborations (CRC Cards) and Scenarios. ECoDE includes a graphical user interface targeting novice software designers and attempts to present an environment that couples the flexible and modular structure of well-designed object-oriented software and perspicuity of functionally organized software.The main interface called the Ectropic Design Navigator consists of two tools namely The CRC Card Navigator and the Scenarios Navigator. The design process consists of three phases:

[[File:designass-3.jpg|center|x400px|ECoDE]]

Analysis mode: This phase involves identifying and analyzing the program goals, identifying candidate classes to meet them, determining the responsibilities and distributing them among the candidate classes. It also involves creating scenarios for identifying the required responsibilities and building Scenarios from a sequence of CRC Card Responsibility pairs.

Design mode: This phase aims at designing a complete and implementable design. It involves reviewing each CRC card and assigning a corresponding method to each responsibility assigned to the card. In this mode the designer can create, categorize, and describe methods and match them with specific responsibilities apart from the tasks available in the analysis phase.

Program Phase: In this phase the tool checks all the CRC cards and makes sure that all the responsibilities have been assigned their corresponding methods. This allows in fixing deficiencies. It also provides the ability to convert CRC cards to actual Classes after which it asks the designer to provide attributes for the class and generates source code stubs which can then be completely implemented by the designer.

=== CRC Design Assistant ===

The CRC Design assistant<ref>[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.118.2233 CRC Design Assistant] A Tool to Support the CRC Design Method </ref> is a freely available software tool that was developed to make the CRC design process easy for students. The system consists of a simple Access database and a set of classes. The database stores the design information for the classes, responsibilities, collaborations, contracts, subsystems, users, and documentation.

[[File:crcda.jpg|center|x300px|CRC Design Assistant]]

Some of the important features of this tool are:

*The CRC view has index cards scattered around the workspace. It uses drag-and-drop to make changes to a design. Dragging one card into another automatically makes changes to both the classes. This ensures that changes in the design are consistent.
*The CRC view also makes identifying classes with too many responsibilities easier and also helps in identifying classes that are too interconnected with the rest of the system.
*The tool provides automatic documentation for the application design. The document is in rich text format (RTF) which can be opened with Microsoft Word or WordPerfect.
*It generates comma separated variable (CSV) files that can be opened with Microsoft Visio to create CRC diagrams and object diagrams.
*Lines are drawn to represent collaborations between classes thus making it easy to visualize the extent of coupling in the system.
*Allows the designer to view the design at different levels of complexity by providing support for subsystem abstraction and grouping classes performing related tasks into a subsystem.
*It allows us to handle the growth in workspace by providing an option to print the CRC cards from the database and use the traditional approach and update the database after a work session. We could also use a projector or an electronic whiteboard for the same.

=== Visual Paradigm for UML ===

Visual Paradigm for UML<ref> [http://www.visual-paradigm.com/product/vpuml/ Visual Paradigm] </ref> is a CASE tool for UML diagrams. It supports thirteen types of diagrams.Type of diagram can be selected from Diagram navigator. The option to select CRC card diagram is found under requirements capturing tab.Selecting a new CRC card diagram opens up a new diagram toolbar. We can create cards by selecting CRC Card from diagram tool. A new CRC card appears on screen. The properties have to be edited. We can edit Card name (class name), Super classes, sub classes, its attributes, its responsibilities and its collaborators. Attributes and responsibilities may be added by right clicking on attributes or responsibilities heading and click on add attribute or responsibility. Name of attribute and description can be entered and while entering responsibility Name and its collaborator are entered.

{|
|[[File:VPadd.png|x300px]]
|[[File:VPattr.png|x300px]]
|}

=== Easy CRC ===

EasyCRC<ref>[http://www.easycrc.com EasyCRC] A. Raman, S. Tyszberowicz. The EasyCRC Tool,
2nd international conference on Software Engineering
Advances (ICSEA), France, 2007
</ref> combines CRC cards and sequence diagrams. It is originally developed to teach Object oriented paradigm. Most of UML tools don’t include CRC cards and diagrams which give conceptual view of the system rather they focus more on implementation view of the system. EasyCRC is the only tool that focuses on CRC cards and scenarios. If any changes occur to sequence diagrams we can make changes to CRC diagrams as well.
It also provides a text editor where the description can be copy pasted and the tool picks out the noun in the description and lists them. We can select the most appropriate nouns from the list and add them to the noun list. We can also select the words that were not listed by the tool by highlighting the word and adding it to noun list.There are two ways to update the responsibilities and collaborators in CRC diagram. First one is we enter all the values manually. The other method is to draw the sequence diagrams first and from these diagrams the responsibilities and collaborators of a class would be identified and updated.

{|
|[[File:easyCRC2.png|x300px]]
|[[File:easyCRC1.png|x300px]]
|}

=== Interactive 3D CRC Cards (Flying Circus) ===

In general 2D diagrams, it is difficult to see the entire diagram and its collaborators. This restricts the process of understanding the diagram and coming up with new collaborators. To avoid these a CRC card diagram can be drawn in a 3D space. Flying Circus<ref> [http://www.csd.uoc.gr/~papadako/files/MSc.pdf 3DCRC] VERY RAPID SOFTWARE-DESIGN PROTOTYPING WITH
INTERACTIVE 3D CRC CARDS </ref> is an automated 3D tool that aids the technique of CRC card design. CRC cards can be created, modified and placed in a 3D environment. The collaborations between the classes can be shown by links between the classes. Cards can be of different sizes, can use different colors and have comments included in it. Different colors make the easily visible however small the card may be. Flying circus is built out of open source projects like OpenSceneGraph(OSG), libsigc++, Flex etc. Flying circus provides functionality like creating CRC card, deleting a CRC card, collaborators update, change of information on CRC card, change of properties of CRC cards, 3D Manipulators to position it at a desired place in 3D space.

[[File:flying3D.png|center|x300px]]

=== Merobase Component Finder ===

It is an online software search engine. It supports simple text based search , interface search , module lookup. The software can be searched and reused. The query is searched in various sources like SourceForge etc. Merobase allows user to define a CRC card and searches its database for matching components and displays it to user. He can reuse the cards and software associated with it. <ref> [http://merobase.com/ merobase] </ref>
[[File:MeroBase.png|center|x300px]]

=== Software Ideas Modeler ===

Software Ideas Modeler <ref> [http://www.freedownloadmanager.org/downloads/crc_card_software/ Software Ideas Modeler] </ref> is a light weight tool that supports 14 types of UML diagrams. On starting the tool it shows all the 14 type of diagrams it supports and asks to choose one among them. After selecting CRC diagram, a diagram toolbox is opened. From there we can select a new CRC card or a link and few other shapes are also provided. When a new CRC card is added, the name can be changed by clicking the name box. The propertied can be edited by double clicking the crc card. This opens up a property pop up box. All the required details can be filled up. At the bottom of CRC a 2 plus symbols is green color are provided. One is to add collaborator and the other one is to add responsibility. A comment button is also provided. All CRC cards can be created and collaborating cards can be linked using a link from diagram tool box.

{|
|[[File:SM1.png|400x500px]]
|[[File:SM2.png|400x500px]]
|}

== Conclusion ==

These are the tools currently available for CRC card design on a computer. Selection of any particular tool can be done by choosing the one which best satisfies our need. The only problem however with using tools for CRC card design is that it is not always best for more than two people to work on the same computer.

= See also =
# [http://en.wikipedia.org/wiki/Unified_Modeling_Language Unified Modeling Language]
# [http://en.wikipedia.org/wiki/Meta-modeling MetaModeling]
# [http://coweb.cc.gatech.edu/cs2340/6046 CRC and Scenario]
# [http://c2.com/doc/oopsla89/paper.html Object Oriented Thinking]
# [http://en.wikipedia.org/wiki/Requirements_analysis Requirement Analysis]
# [https://docs.google.com/viewer?a=v&q=cache:BAN8mwIK1coJ:citeseerx.ist.psu.edu/viewdoc/download%3Fdoi%3D10.1.1.114.7489%26rep%3Drep1%26type%3Dpdf+Software+Design+Using+CRC+Cards&hl=en&gl=us&pid=bl&srcid=ADGEESg5iujWm67Uhw4oJe2ir8J9b1T_tx491dhrl9igQigUOZLMLx5wYbMg5VtJvWu1mmK-9L2WyOuoWhSh_g3Tt63c50I7CdLTxLFFZXVZV7Ry1GZf722lTaBYDC5Ws7Msoj6RA6oG&sig=AHIEtbQLXT9TW9xUdpgapy_8KlO4tZ9Mww Software Design Using CRC Cards]

= References =
<references>
</references>

CSC/ECE 517 Fall 2011/ch4 4i js

2011-10-21T01:11:42Z

Sgade: /* Creating CRC Cards */

== Introduction ==
This Wiki article surveys the various tools that were built to enable CRC card design on a computer. The tools cover both the tools that were developed for commercial purposes as well as the ones that were designed for educational purposes to teach Object Oriented Design.

== CRC CARDS ==
Classes, Responsibilities, and Collaborations [http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card (CRC)] is a design method focused on creating highly cohesive and modular systems. Classes represent the real world entities. They have responsibilities – data and actions the class has to support. These responsibilities can be filled by the class itself or may collaborate with other classes to fulfill it.
CRC cards are 3X5 index cards one for each class. Each has a name and has two columns one for responsibilities and one for collaborators. We can write attributes and description on back of the card.
CRC cards help visualize the design and design can be easily modified by just replacing few cards. These can be useful throughout the life cycle and provides a basis for formal analysis and design methodologies. <ref> [http://books.google.com/books/about/Using_CRC_Cards.html?id=baopCOstm_kC Using CRC Cards: An Informal Approach to Object-Oriented Development]
</ref>

=== Creating CRC Cards ===

CRC Cards help in getting the design right. CRC cards are generated as follows:
1. Discover Classes
2. Determine Responsibilities of each class
3. Describe relationship among each class.

'''Discover Classes:'''The nouns in requirement document translate to classes. We enforce certain rules while choosing classes. Identified Class is a singular noun or one that does not have functionality as some other class or is not simply a primitive type.

'''Determine Responsibilities:''' Responsibilities are the things that class knows or can do. Verbs in requirements document translate to responsibilities.

'''Describe Collaborators:''' Class might need other classes to fulfill certain responsibilities. Those classes can be identified as the collaborators for this class.

{|
|[[File:crccardlayout.jpg|x150px]]
|[[File:CRCCard.jpg|x150px]]
|} <ref>[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2007/wiki2_5_as CRC Card Layout] </ref>

 
The above CRC card describes the class Shopping Cart. A shopping cart must be able to add items and remove items form it so they become responsibilities of that class. It has to collaborate with Product Catalog to add and remove items so Product Catalog becomes collaborator to Shopping Cart

=== Disadvantages of Paper CRC cards ===
*Modification of data in hand written cards is difficult.
*The information on cards needs to be transferred into an electronic medium in order to be used by software development tools.
*As the size of the project grows it’s difficult to maintain CRC cards.
*Difficult to communicate between teams.
*Time consuming.

=== Advantages of a CRC card tool ===
*Easy to maintain cards even as project grows in size.
*It can graphically illustrate relationship between cards.
*New cards can be defined for undefined super classes, subclasses etc.
*Information can be easily entered, updated, deleted.
*Information can be verified easily.
*When renaming a card information on other cards is easily updated.
*Easy to communicate these electronic cards between teams

==CRC Card Tools==

=== Quick CRC ===

QuickCRC <ref> [http://www.excelsoftware.com/quickcrcintro.html QuickCRC]</ref> is a commercial tool developed by Excel Software for designing object-oriented software. It can be used on Mac OS X or Windows.The process of designing a program using QuickCRC involves creating a card for each class, establishing relationships, assigning responsibilities and attributes, defining and simulating scenarios, checking the model for errors and illustrating interesting relationships between objects.

[[File:quickcrc.jpg|center|x300px|Quick CRC Tool]]

A few features supported by this tool are:
*Super and subclasses can be added by selecting from a pop up list of existing cards or by typing the name.
*Provides namespace support for partitioning the cards into different functional areas which can be used while listing specifications, printing cards or exporting information to other tools.
*It can generate the inheritance graphs form the information on the CRC cards.
*Linking cards and scenarios to foreign documents is made easy and thus they can be easily accessed with a single click of the mouse.
*Allows the creation and simulation of scenarios which allows the early identification and correction of bugs.
*The designer can show the attribute access of each card responsibility. QuickCRC automatically graphs the attribute access to highlight attribute usage and incomplete areas of the design and thus allows in locating design problems.
*Information can be imported from other development tools and thus we can generate CRC cards from source code with WinTranslator or MacTranslator.
*Information can be exported to other development tools as the CRC cards can be exported to MacA&D, WinA&D or QuickUML to auto-generate UML class diagrams.
*It can generate a text or HTML coding specification, generate cards, attributes and responsibilities from selected words in a text file or selectively print CRC cards for a peer review. Design work is saved as an XML file.

=== ECoDE (Ectropic Collaborative Design Environment) ===

The Ectropic Collaborative Design Environment, ECoDE<ref> [
http://www.cc.gatech.edu/ectropic/papers/ K. A. Gray, M. Guzdial, and S. Rugaber. Extending
CRC cards into a complete design process. Technical
report, College of Computing, Georgia Institute of
Technology, Atlanta, GA, 2002.] </ref>, is a development tool designed to capture two key components of Ectropic design: Collaborations (CRC Cards) and Scenarios. ECoDE includes a graphical user interface targeting novice software designers and attempts to present an environment that couples the flexible and modular structure of well-designed object-oriented software and perspicuity of functionally organized software.The main interface called the Ectropic Design Navigator consists of two tools namely The CRC Card Navigator and the Scenarios Navigator. The design process consists of three phases:

[[File:designass-3.jpg|center|x400px|ECoDE]]

Analysis mode: This phase involves identifying and analyzing the program goals, identifying candidate classes to meet them, determining the responsibilities and distributing them among the candidate classes. It also involves creating scenarios for identifying the required responsibilities and building Scenarios from a sequence of CRC Card Responsibility pairs.

Design mode: This phase aims at designing a complete and implementable design. It involves reviewing each CRC card and assigning a corresponding method to each responsibility assigned to the card. In this mode the designer can create, categorize, and describe methods and match them with specific responsibilities apart from the tasks available in the analysis phase.

Program Phase: In this phase the tool checks all the CRC cards and makes sure that all the responsibilities have been assigned their corresponding methods. This allows in fixing deficiencies. It also provides the ability to convert CRC cards to actual Classes after which it asks the designer to provide attributes for the class and generates source code stubs which can then be completely implemented by the designer.

=== CRC Design Assistant ===

The CRC Design assistant is a freely available software tool that was developed to make the CRC design process easy for students. The system consists of a simple Access database and a set of classes. The database stores the design information for the classes, responsibilities, collaborations, contracts, subsystems, users, and documentation.

[[File:crcda.jpg|center|x300px|CRC Design Assistant]]

Some of the important features of this tool are:

*The CRC view has index cards scattered around the workspace. It uses drag-and-drop to make changes to a design. Dragging one card into another automatically makes changes to both the classes. This ensures that changes in the design are consistent.
*The CRC view also makes identifying classes with too many responsibilities easier and also helps in identifying classes that are too interconnected with the rest of the system.
*The tool provides automatic documentation for the application design. The document is in rich text format (RTF) which can be opened with Microsoft Word or WordPerfect.
*It generates comma separated variable (CSV) files that can be opened with Microsoft Visio to create CRC diagrams and object diagrams.
*Lines are drawn to represent collaborations between classes thus making it easy to visualize the extent of coupling in the system.
*Allows the designer to view the design at different levels of complexity by providing support for subsystem abstraction and grouping classes performing related tasks into a subsystem.
*It allows us to handle the growth in workspace by providing an option to print the CRC cards from the database and use the traditional approach and update the database after a work session. We could also use a projector or an electronic whiteboard for the same.

=== Visual Paradigm for UML ===

Visual Paradigm for UML is a CASE tool for UML diagrams. It supports thirteen types of diagrams.Type of diagram can be selected from Diagram navigator. The option to select CRC card diagram is found under requirements capturing tab.Selecting a new CRC card diagram opens up a new diagram toolbar. We can create cards by selecting CRC Card from diagram tool. A new CRC card appears on screen. The properties have to be edited. We can edit Card name (class name), Super classes, sub classes, its attributes, its responsibilities and its collaborators. Attributes and responsibilities may be added by right clicking on attributes or responsibilities heading and click on add attribute or responsibility. Name of attribute and description can be entered and while entering responsibility Name and its collaborator are entered.

{|
|[[File:VPadd.png|x300px]]
|[[File:VPattr.png|x300px]]
|}

=== Easy CRC ===

EasyCRC combines CRC cards and sequence diagrams. It is originally developed to teach Object oriented paradigm. Most of UML tools don’t include CRC cards and diagrams which give conceptual view of the system rather they focus more on implementation view of the system. EasyCRC is the only tool that focuses on CRC cards and scenarios. If any changes occur to sequence diagrams we can make changes to CRC diagrams as well.
It also provides a text editor where the description can be copy pasted and the tool picks out the noun in the description and lists them. We can select the most appropriate nouns from the list and add them to the noun list. We can also select the words that were not listed by the tool by highlighting the word and adding it to noun list.There are two ways to update the responsibilities and collaborators in CRC diagram. First one is we enter all the values manually. The other method is to draw the sequence diagrams first and from these diagrams the responsibilities and collaborators of a class would be identified and updated.

{|
|[[File:easyCRC2.png|x300px]]
|[[File:easyCRC1.png|x300px]]
|}

=== Interactive 3D CRC Cards (Flying Circus) ===

In general 2D diagrams, it is difficult to see the entire diagram and its collaborators. This restricts the process of understanding the diagram and coming up with new collaborators. To avoid these a CRC card diagram can be drawn in a 3D space. Flying Circus is an automated 3D tool that aids the technique of CRC card design. CRC cards can be created, modified and placed in a 3D environment. The collaborations between the classes can be shown by links between the classes. Cards can be of different sizes, can use different colors and have comments included in it. Different colors make the easily visible however small the card may be. Flying circus is built out of open source projects like OpenSceneGraph(OSG), libsigc++, Flex etc. Flying circus provides functionality like creating CRC card, deleting a CRC card, collaborators update, change of information on CRC card, change of properties of CRC cards, 3D Manipulators to position it at a desired place in 3D space.

[[File:flying3D.png|center|x300px]]

=== Merobase Component Finder ===

It is an online software search engine. It supports simple text based search , interface search , module lookup. The software can be searched and reused. The query is searched in various sources like SourceForge etc. Merobase allows user to define a CRC card and searches its database for matching components and displays it to user. He can reuse the cards and software associated with it.
[[File:MeroBase.png|center|x300px]]

=== Software Ideas Modeler ===

Software Ideas Modeler is a light weight tool that supports 14 types of UML diagrams. On starting the tool it shows all the 14 type of diagrams it supports and asks to choose one among them. After selecting CRC diagram, a diagram toolbox is opened. From there we can select a new CRC card or a link and few other shapes are also provided. When a new CRC card is added, the name can be changed by clicking the name box. The propertied can be edited by double clicking the crc card. This opens up a property pop up box. All the required details can be filled up. At the bottom of CRC a 2 plus symbols is green color are provided. One is to add collaborator and the other one is to add responsibility. A comment button is also provided. All CRC cards can be created and collaborating cards can be linked using a link from diagram tool box.

{|
|[[File:SM1.png|400x500px]]
|[[File:SM2.png|400x500px]]
|}

== Conclusion ==

These are the tools currently available for CRC card design on a computer. Selection of any particular tool can be done by choosing the one which best satisfies our need. The only problem however with using tools for CRC card design is that it is not always best for more than two people to work on the same computer.

= References =
<references>
</references>

CSC/ECE 517 Fall 2011/ch4 4i js

2011-10-21T01:10:31Z

Sgade: /* Creating CRC Cards */

== Introduction ==
This Wiki article surveys the various tools that were built to enable CRC card design on a computer. The tools cover both the tools that were developed for commercial purposes as well as the ones that were designed for educational purposes to teach Object Oriented Design.

== CRC CARDS ==
Classes, Responsibilities, and Collaborations [http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card (CRC)] is a design method focused on creating highly cohesive and modular systems. Classes represent the real world entities. They have responsibilities – data and actions the class has to support. These responsibilities can be filled by the class itself or may collaborate with other classes to fulfill it.
CRC cards are 3X5 index cards one for each class. Each has a name and has two columns one for responsibilities and one for collaborators. We can write attributes and description on back of the card.
CRC cards help visualize the design and design can be easily modified by just replacing few cards. These can be useful throughout the life cycle and provides a basis for formal analysis and design methodologies. <ref> [http://books.google.com/books/about/Using_CRC_Cards.html?id=baopCOstm_kC Using CRC Cards: An Informal Approach to Object-Oriented Development]
</ref>

=== Creating CRC Cards ===

CRC Cards help in getting the design right. CRC cards are generated as follows:
1. Discover Classes
2. Determine Responsibilities of each class
3. Describe relationship among each class.

'''Discover Classes:'''The nouns in requirement document translate to classes. We enforce certain rules while choosing classes. Identified Class is a singular noun or one that does not have functionality as some other class or is not simply a primitive type.

'''Determine Responsibilities:''' Responsibilities are the things that class knows or can do. Verbs in requirements document translate to responsibilities.

'''Describe Collaborators:''' Class might need other classes to fulfill certain responsibilities. Those classes can be identified as the collaborators for this class.

{|
|[[File:crccardlayout.jpg|x150px]]
|[[File:CRCCard.jpg|x150px]]
|} <ref>[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2007/wiki2_5_as CRC Card Layout] </ref>

 
The above CRC card describes the class Shopping Cart. A shopping cart must be able to items and remove items form it so they become responsibilities of that class. It has to collaborate with Product Catalog to add and remove items so Product Catalog becomes collaborator to Shopping Cart

=== Disadvantages of Paper CRC cards ===
*Modification of data in hand written cards is difficult.
*The information on cards needs to be transferred into an electronic medium in order to be used by software development tools.
*As the size of the project grows it’s difficult to maintain CRC cards.
*Difficult to communicate between teams.
*Time consuming.

=== Advantages of a CRC card tool ===
*Easy to maintain cards even as project grows in size.
*It can graphically illustrate relationship between cards.
*New cards can be defined for undefined super classes, subclasses etc.
*Information can be easily entered, updated, deleted.
*Information can be verified easily.
*When renaming a card information on other cards is easily updated.
*Easy to communicate these electronic cards between teams

==CRC Card Tools==

=== Quick CRC ===

QuickCRC <ref> [http://www.excelsoftware.com/quickcrcintro.html QuickCRC]</ref> is a commercial tool developed by Excel Software for designing object-oriented software. It can be used on Mac OS X or Windows.The process of designing a program using QuickCRC involves creating a card for each class, establishing relationships, assigning responsibilities and attributes, defining and simulating scenarios, checking the model for errors and illustrating interesting relationships between objects.

[[File:quickcrc.jpg|center|x300px|Quick CRC Tool]]

A few features supported by this tool are:
*Super and subclasses can be added by selecting from a pop up list of existing cards or by typing the name.
*Provides namespace support for partitioning the cards into different functional areas which can be used while listing specifications, printing cards or exporting information to other tools.
*It can generate the inheritance graphs form the information on the CRC cards.
*Linking cards and scenarios to foreign documents is made easy and thus they can be easily accessed with a single click of the mouse.
*Allows the creation and simulation of scenarios which allows the early identification and correction of bugs.
*The designer can show the attribute access of each card responsibility. QuickCRC automatically graphs the attribute access to highlight attribute usage and incomplete areas of the design and thus allows in locating design problems.
*Information can be imported from other development tools and thus we can generate CRC cards from source code with WinTranslator or MacTranslator.
*Information can be exported to other development tools as the CRC cards can be exported to MacA&D, WinA&D or QuickUML to auto-generate UML class diagrams.
*It can generate a text or HTML coding specification, generate cards, attributes and responsibilities from selected words in a text file or selectively print CRC cards for a peer review. Design work is saved as an XML file.

=== ECoDE (Ectropic Collaborative Design Environment) ===

The Ectropic Collaborative Design Environment, ECoDE<ref> [
http://www.cc.gatech.edu/ectropic/papers/ K. A. Gray, M. Guzdial, and S. Rugaber. Extending
CRC cards into a complete design process. Technical
report, College of Computing, Georgia Institute of
Technology, Atlanta, GA, 2002.] </ref>, is a development tool designed to capture two key components of Ectropic design: Collaborations (CRC Cards) and Scenarios. ECoDE includes a graphical user interface targeting novice software designers and attempts to present an environment that couples the flexible and modular structure of well-designed object-oriented software and perspicuity of functionally organized software.The main interface called the Ectropic Design Navigator consists of two tools namely The CRC Card Navigator and the Scenarios Navigator. The design process consists of three phases:

[[File:designass-3.jpg|center|x400px|ECoDE]]

Analysis mode: This phase involves identifying and analyzing the program goals, identifying candidate classes to meet them, determining the responsibilities and distributing them among the candidate classes. It also involves creating scenarios for identifying the required responsibilities and building Scenarios from a sequence of CRC Card Responsibility pairs.

Design mode: This phase aims at designing a complete and implementable design. It involves reviewing each CRC card and assigning a corresponding method to each responsibility assigned to the card. In this mode the designer can create, categorize, and describe methods and match them with specific responsibilities apart from the tasks available in the analysis phase.

Program Phase: In this phase the tool checks all the CRC cards and makes sure that all the responsibilities have been assigned their corresponding methods. This allows in fixing deficiencies. It also provides the ability to convert CRC cards to actual Classes after which it asks the designer to provide attributes for the class and generates source code stubs which can then be completely implemented by the designer.

=== CRC Design Assistant ===

The CRC Design assistant is a freely available software tool that was developed to make the CRC design process easy for students. The system consists of a simple Access database and a set of classes. The database stores the design information for the classes, responsibilities, collaborations, contracts, subsystems, users, and documentation.

[[File:crcda.jpg|center|x300px|CRC Design Assistant]]

Some of the important features of this tool are:

*The CRC view has index cards scattered around the workspace. It uses drag-and-drop to make changes to a design. Dragging one card into another automatically makes changes to both the classes. This ensures that changes in the design are consistent.
*The CRC view also makes identifying classes with too many responsibilities easier and also helps in identifying classes that are too interconnected with the rest of the system.
*The tool provides automatic documentation for the application design. The document is in rich text format (RTF) which can be opened with Microsoft Word or WordPerfect.
*It generates comma separated variable (CSV) files that can be opened with Microsoft Visio to create CRC diagrams and object diagrams.
*Lines are drawn to represent collaborations between classes thus making it easy to visualize the extent of coupling in the system.
*Allows the designer to view the design at different levels of complexity by providing support for subsystem abstraction and grouping classes performing related tasks into a subsystem.
*It allows us to handle the growth in workspace by providing an option to print the CRC cards from the database and use the traditional approach and update the database after a work session. We could also use a projector or an electronic whiteboard for the same.

=== Visual Paradigm for UML ===

Visual Paradigm for UML is a CASE tool for UML diagrams. It supports thirteen types of diagrams.Type of diagram can be selected from Diagram navigator. The option to select CRC card diagram is found under requirements capturing tab.Selecting a new CRC card diagram opens up a new diagram toolbar. We can create cards by selecting CRC Card from diagram tool. A new CRC card appears on screen. The properties have to be edited. We can edit Card name (class name), Super classes, sub classes, its attributes, its responsibilities and its collaborators. Attributes and responsibilities may be added by right clicking on attributes or responsibilities heading and click on add attribute or responsibility. Name of attribute and description can be entered and while entering responsibility Name and its collaborator are entered.

{|
|[[File:VPadd.png|x300px]]
|[[File:VPattr.png|x300px]]
|}

=== Easy CRC ===

EasyCRC combines CRC cards and sequence diagrams. It is originally developed to teach Object oriented paradigm. Most of UML tools don’t include CRC cards and diagrams which give conceptual view of the system rather they focus more on implementation view of the system. EasyCRC is the only tool that focuses on CRC cards and scenarios. If any changes occur to sequence diagrams we can make changes to CRC diagrams as well.
It also provides a text editor where the description can be copy pasted and the tool picks out the noun in the description and lists them. We can select the most appropriate nouns from the list and add them to the noun list. We can also select the words that were not listed by the tool by highlighting the word and adding it to noun list.There are two ways to update the responsibilities and collaborators in CRC diagram. First one is we enter all the values manually. The other method is to draw the sequence diagrams first and from these diagrams the responsibilities and collaborators of a class would be identified and updated.

{|
|[[File:easyCRC2.png|x300px]]
|[[File:easyCRC1.png|x300px]]
|}

=== Interactive 3D CRC Cards (Flying Circus) ===

In general 2D diagrams, it is difficult to see the entire diagram and its collaborators. This restricts the process of understanding the diagram and coming up with new collaborators. To avoid these a CRC card diagram can be drawn in a 3D space. Flying Circus is an automated 3D tool that aids the technique of CRC card design. CRC cards can be created, modified and placed in a 3D environment. The collaborations between the classes can be shown by links between the classes. Cards can be of different sizes, can use different colors and have comments included in it. Different colors make the easily visible however small the card may be. Flying circus is built out of open source projects like OpenSceneGraph(OSG), libsigc++, Flex etc. Flying circus provides functionality like creating CRC card, deleting a CRC card, collaborators update, change of information on CRC card, change of properties of CRC cards, 3D Manipulators to position it at a desired place in 3D space.

[[File:flying3D.png|center|x300px]]

=== Merobase Component Finder ===

It is an online software search engine. It supports simple text based search , interface search , module lookup. The software can be searched and reused. The query is searched in various sources like SourceForge etc. Merobase allows user to define a CRC card and searches its database for matching components and displays it to user. He can reuse the cards and software associated with it.
[[File:MeroBase.png|center|x300px]]

=== Software Ideas Modeler ===

Software Ideas Modeler is a light weight tool that supports 14 types of UML diagrams. On starting the tool it shows all the 14 type of diagrams it supports and asks to choose one among them. After selecting CRC diagram, a diagram toolbox is opened. From there we can select a new CRC card or a link and few other shapes are also provided. When a new CRC card is added, the name can be changed by clicking the name box. The propertied can be edited by double clicking the crc card. This opens up a property pop up box. All the required details can be filled up. At the bottom of CRC a 2 plus symbols is green color are provided. One is to add collaborator and the other one is to add responsibility. A comment button is also provided. All CRC cards can be created and collaborating cards can be linked using a link from diagram tool box.

{|
|[[File:SM1.png|400x500px]]
|[[File:SM2.png|400x500px]]
|}

== Conclusion ==

These are the tools currently available for CRC card design on a computer. Selection of any particular tool can be done by choosing the one which best satisfies our need. The only problem however with using tools for CRC card design is that it is not always best for more than two people to work on the same computer.

= References =
<references>
</references>

CSC/ECE 517 Fall 2011/ch4 4i js

2011-10-21T00:58:03Z

Sgade: /* Conclusion */

== Introduction ==
This Wiki article surveys the various tools that were built to enable CRC card design on a computer. The tools cover both the tools that were developed for commercial purposes as well as the ones that were designed for educational purposes to teach Object Oriented Design.

== CRC CARDS ==
Classes, Responsibilities, and Collaborations [http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card (CRC)] is a design method focused on creating highly cohesive and modular systems. Classes represent the real world entities. They have responsibilities – data and actions the class has to support. These responsibilities can be filled by the class itself or may collaborate with other classes to fulfill it.
CRC cards are 3X5 index cards one for each class. Each has a name and has two columns one for responsibilities and one for collaborators. We can write attributes and description on back of the card.
CRC cards help visualize the design and design can be easily modified by just replacing few cards. These can be useful throughout the life cycle and provides a basis for formal analysis and design methodologies. <ref> [http://books.google.com/books/about/Using_CRC_Cards.html?id=baopCOstm_kC Using CRC Cards: An Informal Approach to Object-Oriented Development]
</ref>

=== Creating CRC Cards ===

CRC Cards help in getting the design right. CRC cards are generated as follows:
• Discover Classes
• Determine Responsibilities of each class
• Describe relationship among each class.

'''Discover Classes:'''The nouns in requirement document translate to classes. We enforce certain rules while choosing classes. Identified Class is a singular noun or one that does not have functionality as some other class or is not simply a primitive type.

'''Determine Responsibilities:''' Responsibilities are the things that class knows or can do. Verbs in requirements document translate to responsibilities.

'''Describe Collaborators:''' Class might need other classes to fulfill certain responsibilities. Those classes can be identified as the collaborators for this class.

{|
|[[File:crccardlayout.jpg|x150px]]
|[[File:CRCCard.jpg|x150px]]
|} <ref>[http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2007/wiki2_5_as CRC Card Layout] </ref>

 
The above CRC card describes the class Shopping Cart. A shopping cart must be able to items and remove items form it so they become responsibilities of that class. It has to collaborate with Product Catalog to add and remove items so Product Catalog becomes collaborator to Shopping Cart

=== Disadvantages of Paper CRC cards ===
*Modification of data in hand written cards is difficult.
*The information on cards needs to be transferred into an electronic medium in order to be used by software development tools.
*As the size of the project grows it’s difficult to maintain CRC cards.
*Difficult to communicate between teams.
*Time consuming.

=== Advantages of a CRC card tool ===
*Easy to maintain cards even as project grows in size.
*It can graphically illustrate relationship between cards.
*New cards can be defined for undefined super classes, subclasses etc.
*Information can be easily entered, updated, deleted.
*Information can be verified easily.
*When renaming a card information on other cards is easily updated.
*Easy to communicate these electronic cards between teams

==CRC Card Tools==

=== Quick CRC ===

QuickCRC is a commercial tool developed by Excel Software for designing object-oriented software. It can be used on Mac OS X or Windows.The process of designing a program using QuickCRC involves creating a card for each class, establishing relationships, assigning responsibilities and attributes, defining and simulating scenarios, checking the model for errors and illustrating interesting relationships between objects.

[[File:quickcrc.jpg|center|x300px|Quick CRC Tool]]

A few features supported by this tool are:
*Super and subclasses can be added by selecting from a pop up list of existing cards or by typing the name.
*Provides namespace support for partitioning the cards into different functional areas which can be used while listing specifications, printing cards or exporting information to other tools.
*It can generate the inheritance graphs form the information on the CRC cards.
*Linking cards and scenarios to foreign documents is made easy and thus they can be easily accessed with a single click of the mouse.
*Allows the creation and simulation of scenarios which allows the early identification and correction of bugs.
*The designer can show the attribute access of each card responsibility. QuickCRC automatically graphs the attribute access to highlight attribute usage and incomplete areas of the design and thus allows in locating design problems.
*Information can be imported from other development tools and thus we can generate CRC cards from source code with WinTranslator or MacTranslator.
*Information can be exported to other development tools as the CRC cards can be exported to MacA&D, WinA&D or QuickUML to auto-generate UML class diagrams.
*It can generate a text or HTML coding specification, generate cards, attributes and responsibilities from selected words in a text file or selectively print CRC cards for a peer review. Design work is saved as an XML file.

=== ECoDE (Ectropic Collaborative Design Environment) ===

The Ectropic Collaborative Design Environment, ECoDE, is a development tool designed to capture two key components of Ectropic design: Collaborations (CRC Cards) and Scenarios. ECoDE includes a graphical user interface targeting novice software designers and attempts to present an environment that couples the flexible and modular structure of well-designed object-oriented software and perspicuity of functionally organized software.The main interface called the Ectropic Design Navigator consists of two tools namely The CRC Card Navigator and the Scenarios Navigator. The design process consists of three phases:

[[File:designass-3.jpg|center|x400px|ECoDE]]

Analysis mode: This phase involves identifying and analyzing the program goals, identifying candidate classes to meet them, determining the responsibilities and distributing them among the candidate classes. It also involves creating scenarios for identifying the required responsibilities and building Scenarios from a sequence of CRC Card Responsibility pairs.

Design mode: This phase aims at designing a complete and implementable design. It involves reviewing each CRC card and assigning a corresponding method to each responsibility assigned to the card. In this mode the designer can create, categorize, and describe methods and match them with specific responsibilities apart from the tasks available in the analysis phase.

Program Phase: In this phase the tool checks all the CRC cards and makes sure that all the responsibilities have been assigned their corresponding methods. This allows in fixing deficiencies. It also provides the ability to convert CRC cards to actual Classes after which it asks the designer to provide attributes for the class and generates source code stubs which can then be completely implemented by the designer.

=== CRC Design Assistant ===

The CRC Design assistant is a freely available software tool that was developed to make the CRC design process easy for students. The system consists of a simple Access database and a set of classes. The database stores the design information for the classes, responsibilities, collaborations, contracts, subsystems, users, and documentation.

[[File:crcda.jpg|center|x300px|CRC Design Assistant]]

Some of the important features of this tool are:

*The CRC view has index cards scattered around the workspace. It uses drag-and-drop to make changes to a design. Dragging one card into another automatically makes changes to both the classes. This ensures that changes in the design are consistent.
*The CRC view also makes identifying classes with too many responsibilities easier and also helps in identifying classes that are too interconnected with the rest of the system.
*The tool provides automatic documentation for the application design. The document is in rich text format (RTF) which can be opened with Microsoft Word or WordPerfect.
*It generates comma separated variable (CSV) files that can be opened with Microsoft Visio to create CRC diagrams and object diagrams.
*Lines are drawn to represent collaborations between classes thus making it easy to visualize the extent of coupling in the system.
*Allows the designer to view the design at different levels of complexity by providing support for subsystem abstraction and grouping classes performing related tasks into a subsystem.
*It allows us to handle the growth in workspace by providing an option to print the CRC cards from the database and use the traditional approach and update the database after a work session. We could also use a projector or an electronic whiteboard for the same.

=== Visual Paradigm for UML ===

Visual Paradigm for UML is a CASE tool for UML diagrams. It supports thirteen types of diagrams.Type of diagram can be selected from Diagram navigator. The option to select CRC card diagram is found under requirements capturing tab.Selecting a new CRC card diagram opens up a new diagram toolbar. We can create cards by selecting CRC Card from diagram tool. A new CRC card appears on screen. The properties have to be edited. We can edit Card name (class name), Super classes, sub classes, its attributes, its responsibilities and its collaborators. Attributes and responsibilities may be added by right clicking on attributes or responsibilities heading and click on add attribute or responsibility. Name of attribute and description can be entered and while entering responsibility Name and its collaborator are entered.

{|
|[[File:VPadd.png|x300px]]
|[[File:VPattr.png|x300px]]
|}

=== Easy CRC ===

EasyCRC combines CRC cards and sequence diagrams. It is originally developed to teach Object oriented paradigm. Most of UML tools don’t include CRC cards and diagrams which give conceptual view of the system rather they focus more on implementation view of the system. EasyCRC is the only tool that focuses on CRC cards and scenarios. If any changes occur to sequence diagrams we can make changes to CRC diagrams as well.
It also provides a text editor where the description can be copy pasted and the tool picks out the noun in the description and lists them. We can select the most appropriate nouns from the list and add them to the noun list. We can also select the words that were not listed by the tool by highlighting the word and adding it to noun list.There are two ways to update the responsibilities and collaborators in CRC diagram. First one is we enter all the values manually. The other method is to draw the sequence diagrams first and from these diagrams the responsibilities and collaborators of a class would be identified and updated.

{|
|[[File:easyCRC2.png|x300px]]
|[[File:easyCRC1.png|x300px]]
|}

=== Interactive 3D CRC Cards (Flying Circus) ===

In general 2D diagrams, it is difficult to see the entire diagram and its collaborators. This restricts the process of understanding the diagram and coming up with new collaborators. To avoid these a CRC card diagram can be drawn in a 3D space. Flying Circus is an automated 3D tool that aids the technique of CRC card design. CRC cards can be created, modified and placed in a 3D environment. The collaborations between the classes can be shown by links between the classes. Cards can be of different sizes, can use different colors and have comments included in it. Different colors make the easily visible however small the card may be. Flying circus is built out of open source projects like OpenSceneGraph(OSG), libsigc++, Flex etc. Flying circus provides functionality like creating CRC card, deleting a CRC card, collaborators update, change of information on CRC card, change of properties of CRC cards, 3D Manipulators to position it at a desired place in 3D space.

[[File:flying3D.png|center|x300px]]

=== Merobase Component Finder ===

It is an online software search engine. It supports simple text based search , interface search , module lookup. The software can be searched and reused. The query is searched in various sources like SourceForge etc. Merobase allows user to define a CRC card and searches its database for matching components and displays it to user. He can reuse the cards and software associated with it.
[[File:MeroBase.png|center|x300px]]

=== Software Ideas Modeler ===

Software Ideas Modeler is a light weight tool that supports 14 types of UML diagrams. On starting the tool it shows all the 14 type of diagrams it supports and asks to choose one among them. After selecting CRC diagram, a diagram toolbox is opened. From there we can select a new CRC card or a link and few other shapes are also provided. When a new CRC card is added, the name can be changed by clicking the name box. The propertied can be edited by double clicking the crc card. This opens up a property pop up box. All the required details can be filled up. At the bottom of CRC a 2 plus symbols is green color are provided. One is to add collaborator and the other one is to add responsibility. A comment button is also provided. All CRC cards can be created and collaborating cards can be linked using a link from diagram tool box.

{|
|[[File:SM1.png|400x500px]]
|[[File:SM2.png|400x500px]]
|}

== Conclusion ==

These are the tools currently available for CRC card design on a computer. Selection of any particular tool can be done by choosing the one which best satisfies our need. The only problem however with using tools for CRC card design is that it is not always best for more than two people to work on the same computer.

= References =
<references>
</references>

CSC/ECE 517 Fall 2011/ch4 4i js

2011-10-21T00:46:09Z

Sgade: /* Introduction */

== Introduction ==
This Wiki article surveys the various tools that were built to enable CRC card design on a computer. The tools cover both the tools that were developed for commercial purposes as well as the ones that were designed for educational purposes to teach Object Oriented Design.

== CRC CARDS ==
Classes, Responsibilities, and Collaborations [http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card (CRC)] is a design method focused on creating highly cohesive and modular systems. Classes represent the real world entities. They have responsibilities – data and actions the class has to support. These responsibilities can be filled by the class itself or may collaborate with other classes to fulfill it.
CRC cards are 3X5 index cards one for each class. Each has a name and has two columns one for responsibilities and one for collaborators. We can write attributes and description on back of the card.
CRC cards help visualize the design and design can be easily modified by just replacing few cards. These can be useful throughout the life cycle and provides a basis for formal analysis and design methodologies.

=== Creating CRC Cards ===

CRC Cards help in getting the design right. CRC cards are generated as follows:
• Discover Classes
• Determine Responsibilities of each class
• Describe relationship among each class.

'''Discover Classes:'''The nouns in requirement document translate to classes. We enforce certain rules while choosing classes. Identified Class is a singular noun or one that does not have functionality as some other class or is not simply a primitive type.

'''Determine Responsibilities:''' Responsibilities are the things that class knows or can do. Verbs in requirements document translate to responsibilities.

'''Describe Collaborators:''' Class might need other classes to fulfill certain responsibilities. Those classes can be identified as the collaborators for this class.

{|
|[[File:crccardlayout.jpg|x150px]]
|[[File:CRCCard.jpg|x150px]]
|}

 
The above CRC card describes the class Shopping Cart. A shopping cart must be able to items and remove items form it so they become responsibilities of that class. It has to collaborate with Product Catalog to add and remove items so Product Catalog becomes collaborator to Shopping Cart

=== Disadvantages of Paper CRC cards ===
*Modification of data in hand written cards is difficult.
*The information on cards needs to be transferred into an electronic medium in order to be used by software development tools.
*As the size of the project grows it’s difficult to maintain CRC cards.
*Difficult to communicate between teams.
*Time consuming.

=== Advantages of a CRC card tool ===
*Easy to maintain cards even as project grows in size.
*It can graphically illustrate relationship between cards.
*New cards can be defined for undefined super classes, subclasses etc.
*Information can be easily entered, updated, deleted.
*Information can be verified easily.
*When renaming a card information on other cards is easily updated.
*Easy to communicate these electronic cards between teams

==CRC Card Tools==

=== Quick CRC ===

QuickCRC is a commercial tool developed by Excel Software for designing object-oriented software. It can be used on Mac OS X or Windows.The process of designing a program using QuickCRC involves creating a card for each class, establishing relationships, assigning responsibilities and attributes, defining and simulating scenarios, checking the model for errors and illustrating interesting relationships between objects.

[[File:quickcrc.jpg|center|x300px|Quick CRC Tool]]

A few features supported by this tool are:
*Super and subclasses can be added by selecting from a pop up list of existing cards or by typing the name.
*Provides namespace support for partitioning the cards into different functional areas which can be used while listing specifications, printing cards or exporting information to other tools.
*It can generate the inheritance graphs form the information on the CRC cards.
*Linking cards and scenarios to foreign documents is made easy and thus they can be easily accessed with a single click of the mouse.
*Allows the creation and simulation of scenarios which allows the early identification and correction of bugs.
*The designer can show the attribute access of each card responsibility. QuickCRC automatically graphs the attribute access to highlight attribute usage and incomplete areas of the design and thus allows in locating design problems.
*Information can be imported from other development tools and thus we can generate CRC cards from source code with WinTranslator or MacTranslator.
*Information can be exported to other development tools as the CRC cards can be exported to MacA&D, WinA&D or QuickUML to auto-generate UML class diagrams.
*It can generate a text or HTML coding specification, generate cards, attributes and responsibilities from selected words in a text file or selectively print CRC cards for a peer review. Design work is saved as an XML file.

=== ECoDE (Ectropic Collaborative Design Environment) ===

The Ectropic Collaborative Design Environment, ECoDE, is a development tool designed to capture two key components of Ectropic design: Collaborations (CRC Cards) and Scenarios. ECoDE includes a graphical user interface targeting novice software designers and attempts to present an environment that couples the flexible and modular structure of well-designed object-oriented software and perspicuity of functionally organized software.The main interface called the Ectropic Design Navigator consists of two tools namely The CRC Card Navigator and the Scenarios Navigator. The design process consists of three phases:

[[File:designass-3.jpg|center|x400px|ECoDE]]

Analysis mode: This phase involves identifying and analyzing the program goals, identifying candidate classes to meet them, determining the responsibilities and distributing them among the candidate classes. It also involves creating scenarios for identifying the required responsibilities and building Scenarios from a sequence of CRC Card Responsibility pairs.

Design mode: This phase aims at designing a complete and implementable design. It involves reviewing each CRC card and assigning a corresponding method to each responsibility assigned to the card. In this mode the designer can create, categorize, and describe methods and match them with specific responsibilities apart from the tasks available in the analysis phase.

Program Phase: In this phase the tool checks all the CRC cards and makes sure that all the responsibilities have been assigned their corresponding methods. This allows in fixing deficiencies. It also provides the ability to convert CRC cards to actual Classes after which it asks the designer to provide attributes for the class and generates source code stubs which can then be completely implemented by the designer.

=== CRC Design Assistant ===

The CRC Design assistant is a freely available software tool that was developed to make the CRC design process easy for students. The system consists of a simple Access database and a set of classes. The database stores the design information for the classes, responsibilities, collaborations, contracts, subsystems, users, and documentation.

[[File:crcda.jpg|center|x300px|CRC Design Assistant]]

Some of the important features of this tool are:

*The CRC view has index cards scattered around the workspace. It uses drag-and-drop to make changes to a design. Dragging one card into another automatically makes changes to both the classes. This ensures that changes in the design are consistent.
*The CRC view also makes identifying classes with too many responsibilities easier and also helps in identifying classes that are too interconnected with the rest of the system.
*The tool provides automatic documentation for the application design. The document is in rich text format (RTF) which can be opened with Microsoft Word or WordPerfect.
*It generates comma separated variable (CSV) files that can be opened with Microsoft Visio to create CRC diagrams and object diagrams.
*Lines are drawn to represent collaborations between classes thus making it easy to visualize the extent of coupling in the system.
*Allows the designer to view the design at different levels of complexity by providing support for subsystem abstraction and grouping classes performing related tasks into a subsystem.
*It allows us to handle the growth in workspace by providing an option to print the CRC cards from the database and use the traditional approach and update the database after a work session. We could also use a projector or an electronic whiteboard for the same.

=== Visual Paradigm for UML ===

Visual Paradigm for UML is a CASE tool for UML diagrams. It supports thirteen types of diagrams.Type of diagram can be selected from Diagram navigator. The option to select CRC card diagram is found under requirements capturing tab.Selecting a new CRC card diagram opens up a new diagram toolbar. We can create cards by selecting CRC Card from diagram tool. A new CRC card appears on screen. The properties have to be edited. We can edit Card name (class name), Super classes, sub classes, its attributes, its responsibilities and its collaborators. Attributes and responsibilities may be added by right clicking on attributes or responsibilities heading and click on add attribute or responsibility. Name of attribute and description can be entered and while entering responsibility Name and its collaborator are entered.

{|
|[[File:VPadd.png|x300px]]
|[[File:VPattr.png|x300px]]
|}

=== Easy CRC ===

EasyCRC combines CRC cards and sequence diagrams. It is originally developed to teach Object oriented paradigm. Most of UML tools don’t include CRC cards and diagrams which give conceptual view of the system rather they focus more on implementation view of the system. EasyCRC is the only tool that focuses on CRC cards and scenarios. If any changes occur to sequence diagrams we can make changes to CRC diagrams as well.
It also provides a text editor where the description can be copy pasted and the tool picks out the noun in the description and lists them. We can select the most appropriate nouns from the list and add them to the noun list. We can also select the words that were not listed by the tool by highlighting the word and adding it to noun list.There are two ways to update the responsibilities and collaborators in CRC diagram. First one is we enter all the values manually. The other method is to draw the sequence diagrams first and from these diagrams the responsibilities and collaborators of a class would be identified and updated.

{|
|[[File:easyCRC2.png|x300px]]
|[[File:easyCRC1.png|x300px]]
|}

=== Interactive 3D CRC Cards (Flying Circus) ===

In general 2D diagrams, it is difficult to see the entire diagram and its collaborators. This restricts the process of understanding the diagram and coming up with new collaborators. To avoid these a CRC card diagram can be drawn in a 3D space. Flying Circus is an automated 3D tool that aids the technique of CRC card design. CRC cards can be created, modified and placed in a 3D environment. The collaborations between the classes can be shown by links between the classes. Cards can be of different sizes, can use different colors and have comments included in it. Different colors make the easily visible however small the card may be. Flying circus is built out of open source projects like OpenSceneGraph(OSG), libsigc++, Flex etc. Flying circus provides functionality like creating CRC card, deleting a CRC card, collaborators update, change of information on CRC card, change of properties of CRC cards, 3D Manipulators to position it at a desired place in 3D space.

[[File:flying3D.png|center|x300px]]

=== Merobase Component Finder ===

It is an online software search engine. It supports simple text based search , interface search , module lookup. The software can be searched and reused. The query is searched in various sources like SourceForge etc. Merobase allows user to define a CRC card and searches its database for matching components and displays it to user. He can reuse the cards and software associated with it.
[[File:MeroBase.png|center|x300px]]

=== Software Ideas Modeler ===

Software Ideas Modeler is a light weight tool that supports 14 types of UML diagrams. On starting the tool it shows all the 14 type of diagrams it supports and asks to choose one among them. After selecting CRC diagram, a diagram toolbox is opened. From there we can select a new CRC card or a link and few other shapes are also provided. When a new CRC card is added, the name can be changed by clicking the name box. The propertied can be edited by double clicking the crc card. This opens up a property pop up box. All the required details can be filled up. At the bottom of CRC a 2 plus symbols is green color are provided. One is to add collaborator and the other one is to add responsibility. A comment button is also provided. All CRC cards can be created and collaborating cards can be linked using a link from diagram tool box.

{|
|[[File:SM1.png|400x500px]]
|[[File:SM2.png|400x500px]]
|}

== Conclusion ==

CSC/ECE 517 Fall 2011/ch4 4i js

2011-10-21T00:31:48Z

Sgade: /* ECoDE (Ectropic Collaborative Design Environment) */

== Introduction ==

== CRC CARDS ==
Classes, Responsibilities, and Collaborations (CRC) is a design method focused on creating highly cohesive and modular systems. Classes represent the real world entities. They have responsibilities – data and actions the class has to support. These responsibilities can be filled by the class itself or may collaborate with other classes to fulfill it.
CRC cards are 3X5 index cards one for each class. Each has a name and has two columns one for responsibilities and one for collaborators. We can write attributes and description on back of the card.
CRC cards help visualize the design and design can be easily modified by just replacing few cards. These can be useful throughout the life cycle and provides a basis for formal analysis and design methodologies.

=== Creating CRC Cards ===

CRC Cards help in getting the design right. CRC cards are generated as follows:
• Discover Classes
• Determine Responsibilities of each class
• Describe relationship among each class.

'''Discover Classes:'''The nouns in requirement document translate to classes. We enforce certain rules while choosing classes. Identified Class is a singular noun or one that does not have functionality as some other class or is not simply a primitive type.

'''Determine Responsibilities:''' Responsibilities are the things that class knows or can do. Verbs in requirements document translate to responsibilities.

'''Describe Collaborators:''' Class might need other classes to fulfill certain responsibilities. Those classes can be identified as the collaborators for this class.

{|
|[[File:crccardlayout.jpg|x150px]]
|[[File:CRCCard.jpg|x150px]]
|}

 
The above CRC card describes the class Shopping Cart. A shopping cart must be able to items and remove items form it so they become responsibilities of that class. It has to collaborate with Product Catalog to add and remove items so Product Catalog becomes collaborator to Shopping Cart

=== Disadvantages of Paper CRC cards ===
*Modification of data in hand written cards is difficult.
*The information on cards needs to be transferred into an electronic medium in order to be used by software development tools.
*As the size of the project grows it’s difficult to maintain CRC cards.
*Difficult to communicate between teams.
*Time consuming.

=== Advantages of a CRC card tool ===
*Easy to maintain cards even as project grows in size.
*It can graphically illustrate relationship between cards.
*New cards can be defined for undefined super classes, subclasses etc.
*Information can be easily entered, updated, deleted.
*Information can be verified easily.
*When renaming a card information on other cards is easily updated.
*Easy to communicate these electronic cards between teams

==CRC Card Tools==

=== Quick CRC ===

QuickCRC is a commercial tool developed by Excel Software for designing object-oriented software. It can be used on Mac OS X or Windows.The process of designing a program using QuickCRC involves creating a card for each class, establishing relationships, assigning responsibilities and attributes, defining and simulating scenarios, checking the model for errors and illustrating interesting relationships between objects.

[[File:quickcrc.jpg|center|x300px|Quick CRC Tool]]

A few features supported by this tool are:
*Super and subclasses can be added by selecting from a pop up list of existing cards or by typing the name.
*Provides namespace support for partitioning the cards into different functional areas which can be used while listing specifications, printing cards or exporting information to other tools.
*It can generate the inheritance graphs form the information on the CRC cards.
*Linking cards and scenarios to foreign documents is made easy and thus they can be easily accessed with a single click of the mouse.
*Allows the creation and simulation of scenarios which allows the early identification and correction of bugs.
*The designer can show the attribute access of each card responsibility. QuickCRC automatically graphs the attribute access to highlight attribute usage and incomplete areas of the design and thus allows in locating design problems.
*Information can be imported from other development tools and thus we can generate CRC cards from source code with WinTranslator or MacTranslator.
*Information can be exported to other development tools as the CRC cards can be exported to MacA&D, WinA&D or QuickUML to auto-generate UML class diagrams.
*It can generate a text or HTML coding specification, generate cards, attributes and responsibilities from selected words in a text file or selectively print CRC cards for a peer review. Design work is saved as an XML file.

=== ECoDE (Ectropic Collaborative Design Environment) ===

The Ectropic Collaborative Design Environment, ECoDE, is a development tool designed to capture two key components of Ectropic design: Collaborations (CRC Cards) and Scenarios. ECoDE includes a graphical user interface targeting novice software designers and attempts to present an environment that couples the flexible and modular structure of well-designed object-oriented software and perspicuity of functionally organized software.The main interface called the Ectropic Design Navigator consists of two tools namely The CRC Card Navigator and the Scenarios Navigator. The design process consists of three phases:

[[File:designass-3.jpg|center|x400px|ECoDE]]

Analysis mode: This phase involves identifying and analyzing the program goals, identifying candidate classes to meet them, determining the responsibilities and distributing them among the candidate classes. It also involves creating scenarios for identifying the required responsibilities and building Scenarios from a sequence of CRC Card Responsibility pairs.

Design mode: This phase aims at designing a complete and implementable design. It involves reviewing each CRC card and assigning a corresponding method to each responsibility assigned to the card. In this mode the designer can create, categorize, and describe methods and match them with specific responsibilities apart from the tasks available in the analysis phase.

Program Phase: In this phase the tool checks all the CRC cards and makes sure that all the responsibilities have been assigned their corresponding methods. This allows in fixing deficiencies. It also provides the ability to convert CRC cards to actual Classes after which it asks the designer to provide attributes for the class and generates source code stubs which can then be completely implemented by the designer.

=== CRC Design Assistant ===

The CRC Design assistant is a freely available software tool that was developed to make the CRC design process easy for students. The system consists of a simple Access database and a set of classes. The database stores the design information for the classes, responsibilities, collaborations, contracts, subsystems, users, and documentation.

[[File:crcda.jpg|center|x300px|CRC Design Assistant]]

Some of the important features of this tool are:

*The CRC view has index cards scattered around the workspace. It uses drag-and-drop to make changes to a design. Dragging one card into another automatically makes changes to both the classes. This ensures that changes in the design are consistent.
*The CRC view also makes identifying classes with too many responsibilities easier and also helps in identifying classes that are too interconnected with the rest of the system.
*The tool provides automatic documentation for the application design. The document is in rich text format (RTF) which can be opened with Microsoft Word or WordPerfect.
*It generates comma separated variable (CSV) files that can be opened with Microsoft Visio to create CRC diagrams and object diagrams.
*Lines are drawn to represent collaborations between classes thus making it easy to visualize the extent of coupling in the system.
*Allows the designer to view the design at different levels of complexity by providing support for subsystem abstraction and grouping classes performing related tasks into a subsystem.
*It allows us to handle the growth in workspace by providing an option to print the CRC cards from the database and use the traditional approach and update the database after a work session. We could also use a projector or an electronic whiteboard for the same.

=== Visual Paradigm for UML ===

Visual Paradigm for UML is a CASE tool for UML diagrams. It supports thirteen types of diagrams.Type of diagram can be selected from Diagram navigator. The option to select CRC card diagram is found under requirements capturing tab.Selecting a new CRC card diagram opens up a new diagram toolbar. We can create cards by selecting CRC Card from diagram tool. A new CRC card appears on screen. The properties have to be edited. We can edit Card name (class name), Super classes, sub classes, its attributes, its responsibilities and its collaborators. Attributes and responsibilities may be added by right clicking on attributes or responsibilities heading and click on add attribute or responsibility. Name of attribute and description can be entered and while entering responsibility Name and its collaborator are entered.

{|
|[[File:VPadd.png|x300px]]
|[[File:VPattr.png|x300px]]
|}

=== Easy CRC ===

EasyCRC combines CRC cards and sequence diagrams. It is originally developed to teach Object oriented paradigm. Most of UML tools don’t include CRC cards and diagrams which give conceptual view of the system rather they focus more on implementation view of the system. EasyCRC is the only tool that focuses on CRC cards and scenarios. If any changes occur to sequence diagrams we can make changes to CRC diagrams as well.
It also provides a text editor where the description can be copy pasted and the tool picks out the noun in the description and lists them. We can select the most appropriate nouns from the list and add them to the noun list. We can also select the words that were not listed by the tool by highlighting the word and adding it to noun list.There are two ways to update the responsibilities and collaborators in CRC diagram. First one is we enter all the values manually. The other method is to draw the sequence diagrams first and from these diagrams the responsibilities and collaborators of a class would be identified and updated.

{|
|[[File:easyCRC1.jpg|400x500px]]
|[[File:easyCRC2.jpg|400x500px]]
|}

=== Interactive 3D CRC Cards (Flying Circus) ===

In general 2D diagrams, it is difficult to see the entire diagram and its collaborators. This restricts the process of understanding the diagram and coming up with new collaborators. To avoid these a CRC card diagram can be drawn in a 3D space. Flying Circus is an automated 3D tool that aids the technique of CRC card design. CRC cards can be created, modified and placed in a 3D environment. The collaborations between the classes can be shown by links between the classes. Cards can be of different sizes, can use different colors and have comments included in it. Different colors make the easily visible however small the card may be. Flying circus is built out of open source projects like OpenSceneGraph(OSG), libsigc++, Flex etc. Flying circus provides functionality like creating CRC card, deleting a CRC card, collaborators update, change of information on CRC card, change of properties of CRC cards, 3D Manipulators to position it at a desired place in 3D space.

[[File:flying3D.png|center|x300px]]

=== Merobase Component Finder ===

It is an online software search engine. It supports simple text based search , interface search , module lookup. The software can be searched and reused. The query is searched in various sources like SourceForge etc. Merobase allows user to define a CRC card and searches its database for matching components and displays it to user. He can reuse the cards and software associated with it.
[[File:MeroBase.png|center|x300px]]

=== Software Ideas Modeler ===

Software Ideas Modeler is a light weight tool that supports 14 types of UML diagrams. On starting the tool it shows all the 14 type of diagrams it supports and asks to choose one among them. After selecting CRC diagram, a diagram toolbox is opened. From there we can select a new CRC card or a link and few other shapes are also provided. When a new CRC card is added, the name can be changed by clicking the name box. The propertied can be edited by double clicking the crc card. This opens up a property pop up box. All the required details can be filled up. At the bottom of CRC a 2 plus symbols is green color are provided. One is to add collaborator and the other one is to add responsibility. A comment button is also provided. All CRC cards can be created and collaborating cards can be linked using a link from diagram tool box.

{|
|[[File:SM1.png|400x500px]]
|[[File:SM2.png|400x500px]]
|}

File:Designass-3.jpg

2011-10-21T00:31:28Z

Sgade:

CSC/ECE 517 Fall 2011/ch4 4i js

2011-10-21T00:31:14Z

Sgade: /* ECoDE (Ectropic Collaborative Design Environment) */

== Introduction ==

== CRC CARDS ==
Classes, Responsibilities, and Collaborations (CRC) is a design method focused on creating highly cohesive and modular systems. Classes represent the real world entities. They have responsibilities – data and actions the class has to support. These responsibilities can be filled by the class itself or may collaborate with other classes to fulfill it.
CRC cards are 3X5 index cards one for each class. Each has a name and has two columns one for responsibilities and one for collaborators. We can write attributes and description on back of the card.
CRC cards help visualize the design and design can be easily modified by just replacing few cards. These can be useful throughout the life cycle and provides a basis for formal analysis and design methodologies.

=== Creating CRC Cards ===

CRC Cards help in getting the design right. CRC cards are generated as follows:
• Discover Classes
• Determine Responsibilities of each class
• Describe relationship among each class.

'''Discover Classes:'''The nouns in requirement document translate to classes. We enforce certain rules while choosing classes. Identified Class is a singular noun or one that does not have functionality as some other class or is not simply a primitive type.

'''Determine Responsibilities:''' Responsibilities are the things that class knows or can do. Verbs in requirements document translate to responsibilities.

'''Describe Collaborators:''' Class might need other classes to fulfill certain responsibilities. Those classes can be identified as the collaborators for this class.

{|
|[[File:crccardlayout.jpg|x150px]]
|[[File:CRCCard.jpg|x150px]]
|}

 
The above CRC card describes the class Shopping Cart. A shopping cart must be able to items and remove items form it so they become responsibilities of that class. It has to collaborate with Product Catalog to add and remove items so Product Catalog becomes collaborator to Shopping Cart

=== Disadvantages of Paper CRC cards ===
*Modification of data in hand written cards is difficult.
*The information on cards needs to be transferred into an electronic medium in order to be used by software development tools.
*As the size of the project grows it’s difficult to maintain CRC cards.
*Difficult to communicate between teams.
*Time consuming.

=== Advantages of a CRC card tool ===
*Easy to maintain cards even as project grows in size.
*It can graphically illustrate relationship between cards.
*New cards can be defined for undefined super classes, subclasses etc.
*Information can be easily entered, updated, deleted.
*Information can be verified easily.
*When renaming a card information on other cards is easily updated.
*Easy to communicate these electronic cards between teams

==CRC Card Tools==

=== Quick CRC ===

QuickCRC is a commercial tool developed by Excel Software for designing object-oriented software. It can be used on Mac OS X or Windows.The process of designing a program using QuickCRC involves creating a card for each class, establishing relationships, assigning responsibilities and attributes, defining and simulating scenarios, checking the model for errors and illustrating interesting relationships between objects.

[[File:quickcrc.jpg|center|x300px|Quick CRC Tool]]

A few features supported by this tool are:
*Super and subclasses can be added by selecting from a pop up list of existing cards or by typing the name.
*Provides namespace support for partitioning the cards into different functional areas which can be used while listing specifications, printing cards or exporting information to other tools.
*It can generate the inheritance graphs form the information on the CRC cards.
*Linking cards and scenarios to foreign documents is made easy and thus they can be easily accessed with a single click of the mouse.
*Allows the creation and simulation of scenarios which allows the early identification and correction of bugs.
*The designer can show the attribute access of each card responsibility. QuickCRC automatically graphs the attribute access to highlight attribute usage and incomplete areas of the design and thus allows in locating design problems.
*Information can be imported from other development tools and thus we can generate CRC cards from source code with WinTranslator or MacTranslator.
*Information can be exported to other development tools as the CRC cards can be exported to MacA&D, WinA&D or QuickUML to auto-generate UML class diagrams.
*It can generate a text or HTML coding specification, generate cards, attributes and responsibilities from selected words in a text file or selectively print CRC cards for a peer review. Design work is saved as an XML file.

=== ECoDE (Ectropic Collaborative Design Environment) ===

The Ectropic Collaborative Design Environment, ECoDE, is a development tool designed to capture two key components of Ectropic design: Collaborations (CRC Cards) and Scenarios. ECoDE includes a graphical user interface targeting novice software designers and attempts to present an environment that couples the flexible and modular structure of well-designed object-oriented software and perspicuity of functionally organized software.The main interface called the Ectropic Design Navigator consists of two tools namely The CRC Card Navigator and the Scenarios Navigator. The design process consists of three phases:

[[File:designass-3.jpg|center|x300px|ECoDE]]

Analysis mode: This phase involves identifying and analyzing the program goals, identifying candidate classes to meet them, determining the responsibilities and distributing them among the candidate classes. It also involves creating scenarios for identifying the required responsibilities and building Scenarios from a sequence of CRC Card Responsibility pairs.

Design mode: This phase aims at designing a complete and implementable design. It involves reviewing each CRC card and assigning a corresponding method to each responsibility assigned to the card. In this mode the designer can create, categorize, and describe methods and match them with specific responsibilities apart from the tasks available in the analysis phase.

Program Phase: In this phase the tool checks all the CRC cards and makes sure that all the responsibilities have been assigned their corresponding methods. This allows in fixing deficiencies. It also provides the ability to convert CRC cards to actual Classes after which it asks the designer to provide attributes for the class and generates source code stubs which can then be completely implemented by the designer.

=== CRC Design Assistant ===

The CRC Design assistant is a freely available software tool that was developed to make the CRC design process easy for students. The system consists of a simple Access database and a set of classes. The database stores the design information for the classes, responsibilities, collaborations, contracts, subsystems, users, and documentation.

[[File:crcda.jpg|center|x300px|CRC Design Assistant]]

Some of the important features of this tool are:

*The CRC view has index cards scattered around the workspace. It uses drag-and-drop to make changes to a design. Dragging one card into another automatically makes changes to both the classes. This ensures that changes in the design are consistent.
*The CRC view also makes identifying classes with too many responsibilities easier and also helps in identifying classes that are too interconnected with the rest of the system.
*The tool provides automatic documentation for the application design. The document is in rich text format (RTF) which can be opened with Microsoft Word or WordPerfect.
*It generates comma separated variable (CSV) files that can be opened with Microsoft Visio to create CRC diagrams and object diagrams.
*Lines are drawn to represent collaborations between classes thus making it easy to visualize the extent of coupling in the system.
*Allows the designer to view the design at different levels of complexity by providing support for subsystem abstraction and grouping classes performing related tasks into a subsystem.
*It allows us to handle the growth in workspace by providing an option to print the CRC cards from the database and use the traditional approach and update the database after a work session. We could also use a projector or an electronic whiteboard for the same.

=== Visual Paradigm for UML ===

Visual Paradigm for UML is a CASE tool for UML diagrams. It supports thirteen types of diagrams.Type of diagram can be selected from Diagram navigator. The option to select CRC card diagram is found under requirements capturing tab.Selecting a new CRC card diagram opens up a new diagram toolbar. We can create cards by selecting CRC Card from diagram tool. A new CRC card appears on screen. The properties have to be edited. We can edit Card name (class name), Super classes, sub classes, its attributes, its responsibilities and its collaborators. Attributes and responsibilities may be added by right clicking on attributes or responsibilities heading and click on add attribute or responsibility. Name of attribute and description can be entered and while entering responsibility Name and its collaborator are entered.

{|
|[[File:VPadd.png|x300px]]
|[[File:VPattr.png|x300px]]
|}

=== Easy CRC ===

EasyCRC combines CRC cards and sequence diagrams. It is originally developed to teach Object oriented paradigm. Most of UML tools don’t include CRC cards and diagrams which give conceptual view of the system rather they focus more on implementation view of the system. EasyCRC is the only tool that focuses on CRC cards and scenarios. If any changes occur to sequence diagrams we can make changes to CRC diagrams as well.
It also provides a text editor where the description can be copy pasted and the tool picks out the noun in the description and lists them. We can select the most appropriate nouns from the list and add them to the noun list. We can also select the words that were not listed by the tool by highlighting the word and adding it to noun list.There are two ways to update the responsibilities and collaborators in CRC diagram. First one is we enter all the values manually. The other method is to draw the sequence diagrams first and from these diagrams the responsibilities and collaborators of a class would be identified and updated.

=== Interactive 3D CRC Cards (Flying Circus) ===

In general 2D diagrams, it is difficult to see the entire diagram and its collaborators. This restricts the process of understanding the diagram and coming up with new collaborators. To avoid these a CRC card diagram can be drawn in a 3D space. Flying Circus is an automated 3D tool that aids the technique of CRC card design. CRC cards can be created, modified and placed in a 3D environment. The collaborations between the classes can be shown by links between the classes. Cards can be of different sizes, can use different colors and have comments included in it. Different colors make the easily visible however small the card may be. Flying circus is built out of open source projects like OpenSceneGraph(OSG), libsigc++, Flex etc. Flying circus provides functionality like creating CRC card, deleting a CRC card, collaborators update, change of information on CRC card, change of properties of CRC cards, 3D Manipulators to position it at a desired place in 3D space.

[[File:flying3D.png|center|x300px]]

=== Merobase Component Finder ===

It is an online software search engine. It supports simple text based search , interface search , module lookup. The software can be searched and reused. The query is searched in various sources like SourceForge etc. Merobase allows user to define a CRC card and searches its database for matching components and displays it to user. He can reuse the cards and software associated with it.
[[File:MeroBase.png|center|x300px]]

=== Software Ideas Modeler ===

Software Ideas Modeler is a light weight tool that supports 14 types of UML diagrams. On starting the tool it shows all the 14 type of diagrams it supports and asks to choose one among them. After selecting CRC diagram, a diagram toolbox is opened. From there we can select a new CRC card or a link and few other shapes are also provided. When a new CRC card is added, the name can be changed by clicking the name box. The propertied can be edited by double clicking the crc card. This opens up a property pop up box. All the required details can be filled up. At the bottom of CRC a 2 plus symbols is green color are provided. One is to add collaborator and the other one is to add responsibility. A comment button is also provided. All CRC cards can be created and collaborating cards can be linked using a link from diagram tool box.

{|
|[[File:SM1.png|400x500px]]
|[[File:SM2.png|400x500px]]
|}

CSC/ECE 517 Fall 2011/ch4 4i js

2011-10-21T00:30:32Z

Sgade: /* ECoDE (Ectropic Collaborative Design Environment) */

== Introduction ==

== CRC CARDS ==
Classes, Responsibilities, and Collaborations (CRC) is a design method focused on creating highly cohesive and modular systems. Classes represent the real world entities. They have responsibilities – data and actions the class has to support. These responsibilities can be filled by the class itself or may collaborate with other classes to fulfill it.
CRC cards are 3X5 index cards one for each class. Each has a name and has two columns one for responsibilities and one for collaborators. We can write attributes and description on back of the card.
CRC cards help visualize the design and design can be easily modified by just replacing few cards. These can be useful throughout the life cycle and provides a basis for formal analysis and design methodologies.

=== Creating CRC Cards ===

CRC Cards help in getting the design right. CRC cards are generated as follows:
• Discover Classes
• Determine Responsibilities of each class
• Describe relationship among each class.

'''Discover Classes:'''The nouns in requirement document translate to classes. We enforce certain rules while choosing classes. Identified Class is a singular noun or one that does not have functionality as some other class or is not simply a primitive type.

'''Determine Responsibilities:''' Responsibilities are the things that class knows or can do. Verbs in requirements document translate to responsibilities.

'''Describe Collaborators:''' Class might need other classes to fulfill certain responsibilities. Those classes can be identified as the collaborators for this class.

{|
|[[File:crccardlayout.jpg|x150px]]
|[[File:CRCCard.jpg|x150px]]
|}

 
The above CRC card describes the class Shopping Cart. A shopping cart must be able to items and remove items form it so they become responsibilities of that class. It has to collaborate with Product Catalog to add and remove items so Product Catalog becomes collaborator to Shopping Cart

=== Disadvantages of Paper CRC cards ===
*Modification of data in hand written cards is difficult.
*The information on cards needs to be transferred into an electronic medium in order to be used by software development tools.
*As the size of the project grows it’s difficult to maintain CRC cards.
*Difficult to communicate between teams.
*Time consuming.

=== Advantages of a CRC card tool ===
*Easy to maintain cards even as project grows in size.
*It can graphically illustrate relationship between cards.
*New cards can be defined for undefined super classes, subclasses etc.
*Information can be easily entered, updated, deleted.
*Information can be verified easily.
*When renaming a card information on other cards is easily updated.
*Easy to communicate these electronic cards between teams

==CRC Card Tools==

=== Quick CRC ===

QuickCRC is a commercial tool developed by Excel Software for designing object-oriented software. It can be used on Mac OS X or Windows.The process of designing a program using QuickCRC involves creating a card for each class, establishing relationships, assigning responsibilities and attributes, defining and simulating scenarios, checking the model for errors and illustrating interesting relationships between objects.

[[File:quickcrc.jpg|center|x300px|Quick CRC Tool]]

A few features supported by this tool are:
*Super and subclasses can be added by selecting from a pop up list of existing cards or by typing the name.
*Provides namespace support for partitioning the cards into different functional areas which can be used while listing specifications, printing cards or exporting information to other tools.
*It can generate the inheritance graphs form the information on the CRC cards.
*Linking cards and scenarios to foreign documents is made easy and thus they can be easily accessed with a single click of the mouse.
*Allows the creation and simulation of scenarios which allows the early identification and correction of bugs.
*The designer can show the attribute access of each card responsibility. QuickCRC automatically graphs the attribute access to highlight attribute usage and incomplete areas of the design and thus allows in locating design problems.
*Information can be imported from other development tools and thus we can generate CRC cards from source code with WinTranslator or MacTranslator.
*Information can be exported to other development tools as the CRC cards can be exported to MacA&D, WinA&D or QuickUML to auto-generate UML class diagrams.
*It can generate a text or HTML coding specification, generate cards, attributes and responsibilities from selected words in a text file or selectively print CRC cards for a peer review. Design work is saved as an XML file.

=== ECoDE (Ectropic Collaborative Design Environment) ===

The Ectropic Collaborative Design Environment, ECoDE, is a development tool designed to capture two key components of Ectropic design: Collaborations (CRC Cards) and Scenarios. ECoDE includes a graphical user interface targeting novice software designers and attempts to present an environment that couples the flexible and modular structure of well-designed object-oriented software and perspicuity of functionally organized software.The main interface called the Ectropic Design Navigator consists of two tools namely The CRC Card Navigator and the Scenarios Navigator. The design process consists of three phases:

[[File:designass-3.jpg|center|x300px]]

Analysis mode: This phase involves identifying and analyzing the program goals, identifying candidate classes to meet them, determining the responsibilities and distributing them among the candidate classes. It also involves creating scenarios for identifying the required responsibilities and building Scenarios from a sequence of CRC Card Responsibility pairs.

Design mode: This phase aims at designing a complete and implementable design. It involves reviewing each CRC card and assigning a corresponding method to each responsibility assigned to the card. In this mode the designer can create, categorize, and describe methods and match them with specific responsibilities apart from the tasks available in the analysis phase.

Program Phase: In this phase the tool checks all the CRC cards and makes sure that all the responsibilities have been assigned their corresponding methods. This allows in fixing deficiencies. It also provides the ability to convert CRC cards to actual Classes after which it asks the designer to provide attributes for the class and generates source code stubs which can then be completely implemented by the designer.

=== CRC Design Assistant ===

The CRC Design assistant is a freely available software tool that was developed to make the CRC design process easy for students. The system consists of a simple Access database and a set of classes. The database stores the design information for the classes, responsibilities, collaborations, contracts, subsystems, users, and documentation.

[[File:crcda.jpg|center|x300px|CRC Design Assistant]]

Some of the important features of this tool are:

*The CRC view has index cards scattered around the workspace. It uses drag-and-drop to make changes to a design. Dragging one card into another automatically makes changes to both the classes. This ensures that changes in the design are consistent.
*The CRC view also makes identifying classes with too many responsibilities easier and also helps in identifying classes that are too interconnected with the rest of the system.
*The tool provides automatic documentation for the application design. The document is in rich text format (RTF) which can be opened with Microsoft Word or WordPerfect.
*It generates comma separated variable (CSV) files that can be opened with Microsoft Visio to create CRC diagrams and object diagrams.
*Lines are drawn to represent collaborations between classes thus making it easy to visualize the extent of coupling in the system.
*Allows the designer to view the design at different levels of complexity by providing support for subsystem abstraction and grouping classes performing related tasks into a subsystem.
*It allows us to handle the growth in workspace by providing an option to print the CRC cards from the database and use the traditional approach and update the database after a work session. We could also use a projector or an electronic whiteboard for the same.

=== Visual Paradigm for UML ===

Visual Paradigm for UML is a CASE tool for UML diagrams. It supports thirteen types of diagrams.Type of diagram can be selected from Diagram navigator. The option to select CRC card diagram is found under requirements capturing tab.Selecting a new CRC card diagram opens up a new diagram toolbar. We can create cards by selecting CRC Card from diagram tool. A new CRC card appears on screen. The properties have to be edited. We can edit Card name (class name), Super classes, sub classes, its attributes, its responsibilities and its collaborators. Attributes and responsibilities may be added by right clicking on attributes or responsibilities heading and click on add attribute or responsibility. Name of attribute and description can be entered and while entering responsibility Name and its collaborator are entered.

{|
|[[File:VPadd.png|x300px]]
|[[File:VPattr.png|x300px]]
|}

=== Easy CRC ===

EasyCRC combines CRC cards and sequence diagrams. It is originally developed to teach Object oriented paradigm. Most of UML tools don’t include CRC cards and diagrams which give conceptual view of the system rather they focus more on implementation view of the system. EasyCRC is the only tool that focuses on CRC cards and scenarios. If any changes occur to sequence diagrams we can make changes to CRC diagrams as well.
It also provides a text editor where the description can be copy pasted and the tool picks out the noun in the description and lists them. We can select the most appropriate nouns from the list and add them to the noun list. We can also select the words that were not listed by the tool by highlighting the word and adding it to noun list.There are two ways to update the responsibilities and collaborators in CRC diagram. First one is we enter all the values manually. The other method is to draw the sequence diagrams first and from these diagrams the responsibilities and collaborators of a class would be identified and updated.

=== Interactive 3D CRC Cards (Flying Circus) ===

In general 2D diagrams, it is difficult to see the entire diagram and its collaborators. This restricts the process of understanding the diagram and coming up with new collaborators. To avoid these a CRC card diagram can be drawn in a 3D space. Flying Circus is an automated 3D tool that aids the technique of CRC card design. CRC cards can be created, modified and placed in a 3D environment. The collaborations between the classes can be shown by links between the classes. Cards can be of different sizes, can use different colors and have comments included in it. Different colors make the easily visible however small the card may be. Flying circus is built out of open source projects like OpenSceneGraph(OSG), libsigc++, Flex etc. Flying circus provides functionality like creating CRC card, deleting a CRC card, collaborators update, change of information on CRC card, change of properties of CRC cards, 3D Manipulators to position it at a desired place in 3D space.

[[File:flying3D.png|center|x300px]]

=== Merobase Component Finder ===

It is an online software search engine. It supports simple text based search , interface search , module lookup. The software can be searched and reused. The query is searched in various sources like SourceForge etc. Merobase allows user to define a CRC card and searches its database for matching components and displays it to user. He can reuse the cards and software associated with it.
[[File:MeroBase.png|center|x300px]]

=== Software Ideas Modeler ===

Software Ideas Modeler is a light weight tool that supports 14 types of UML diagrams. On starting the tool it shows all the 14 type of diagrams it supports and asks to choose one among them. After selecting CRC diagram, a diagram toolbox is opened. From there we can select a new CRC card or a link and few other shapes are also provided. When a new CRC card is added, the name can be changed by clicking the name box. The propertied can be edited by double clicking the crc card. This opens up a property pop up box. All the required details can be filled up. At the bottom of CRC a 2 plus symbols is green color are provided. One is to add collaborator and the other one is to add responsibility. A comment button is also provided. All CRC cards can be created and collaborating cards can be linked using a link from diagram tool box.

{|
|[[File:SM1.png|400x500px]]
|[[File:SM2.png|400x500px]]
|}

File:Crcda.jpg

2011-10-21T00:26:43Z

Sgade:

CSC/ECE 517 Fall 2011/ch4 4i js

2011-10-21T00:26:27Z

Sgade: /* CRC Design Assistant */

== Introduction ==

== CRC CARDS ==
Classes, Responsibilities, and Collaborations (CRC) is a design method focused on creating highly cohesive and modular systems. Classes represent the real world entities. They have responsibilities – data and actions the class has to support. These responsibilities can be filled by the class itself or may collaborate with other classes to fulfill it.
CRC cards are 3X5 index cards one for each class. Each has a name and has two columns one for responsibilities and one for collaborators. We can write attributes and description on back of the card.
CRC cards help visualize the design and design can be easily modified by just replacing few cards. These can be useful throughout the life cycle and provides a basis for formal analysis and design methodologies.

=== Creating CRC Cards ===

CRC Cards help in getting the design right. CRC cards are generated as follows:
• Discover Classes
• Determine Responsibilities of each class
• Describe relationship among each class.

'''Discover Classes:'''The nouns in requirement document translate to classes. We enforce certain rules while choosing classes. Identified Class is a singular noun or one that does not have functionality as some other class or is not simply a primitive type.

'''Determine Responsibilities:''' Responsibilities are the things that class knows or can do. Verbs in requirements document translate to responsibilities.

'''Describe Collaborators:''' Class might need other classes to fulfill certain responsibilities. Those classes can be identified as the collaborators for this class.

{|
|[[File:crccardlayout.jpg|x150px]]
|[[File:CRCCard.jpg|x150px]]
|}

 
The above CRC card describes the class Shopping Cart. A shopping cart must be able to items and remove items form it so they become responsibilities of that class. It has to collaborate with Product Catalog to add and remove items so Product Catalog becomes collaborator to Shopping Cart

=== Disadvantages of Paper CRC cards ===
*Modification of data in hand written cards is difficult.
*The information on cards needs to be transferred into an electronic medium in order to be used by software development tools.
*As the size of the project grows it’s difficult to maintain CRC cards.
*Difficult to communicate between teams.
*Time consuming.

=== Advantages of a CRC card tool ===
*Easy to maintain cards even as project grows in size.
*It can graphically illustrate relationship between cards.
*New cards can be defined for undefined super classes, subclasses etc.
*Information can be easily entered, updated, deleted.
*Information can be verified easily.
*When renaming a card information on other cards is easily updated.
*Easy to communicate these electronic cards between teams

==CRC Card Tools==

=== Quick CRC ===

QuickCRC is a commercial tool developed by Excel Software for designing object-oriented software. It can be used on Mac OS X or Windows.The process of designing a program using QuickCRC involves creating a card for each class, establishing relationships, assigning responsibilities and attributes, defining and simulating scenarios, checking the model for errors and illustrating interesting relationships between objects.

[[File:quickcrc.jpg|center|x300px|Quick CRC Tool]]

A few features supported by this tool are:
*Super and subclasses can be added by selecting from a pop up list of existing cards or by typing the name.
*Provides namespace support for partitioning the cards into different functional areas which can be used while listing specifications, printing cards or exporting information to other tools.
*It can generate the inheritance graphs form the information on the CRC cards.
*Linking cards and scenarios to foreign documents is made easy and thus they can be easily accessed with a single click of the mouse.
*Allows the creation and simulation of scenarios which allows the early identification and correction of bugs.
*The designer can show the attribute access of each card responsibility. QuickCRC automatically graphs the attribute access to highlight attribute usage and incomplete areas of the design and thus allows in locating design problems.
*Information can be imported from other development tools and thus we can generate CRC cards from source code with WinTranslator or MacTranslator.
*Information can be exported to other development tools as the CRC cards can be exported to MacA&D, WinA&D or QuickUML to auto-generate UML class diagrams.
*It can generate a text or HTML coding specification, generate cards, attributes and responsibilities from selected words in a text file or selectively print CRC cards for a peer review. Design work is saved as an XML file.

=== ECoDE (Ectropic Collaborative Design Environment) ===

The Ectropic Collaborative Design Environment, ECoDE, is a development tool designed to capture two key components of Ectropic design: Collaborations (CRC Cards) and Scenarios. ECoDE includes a graphical user interface targeting novice software designers and attempts to present an environment that couples the flexible and modular structure of well-designed object-oriented software and perspicuity of functionally organized software.The main interface called the Ectropic Design Navigator consists of two tools namely The CRC Card Navigator and the Scenarios Navigator. The design process consists of three phases:

Analysis mode: This phase involves identifying and analyzing the program goals, identifying candidate classes to meet them, determining the responsibilities and distributing them among the candidate classes. It also involves creating scenarios for identifying the required responsibilities and building Scenarios from a sequence of CRC Card Responsibility pairs.

Design mode: This phase aims at designing a complete and implementable design. It involves reviewing each CRC card and assigning a corresponding method to each responsibility assigned to the card. In this mode the designer can create, categorize, and describe methods and match them with specific responsibilities apart from the tasks available in the analysis phase.

Program Phase: In this phase the tool checks all the CRC cards and makes sure that all the responsibilities have been assigned their corresponding methods. This allows in fixing deficiencies. It also provides the ability to convert CRC cards to actual Classes after which it asks the designer to provide attributes for the class and generates source code stubs which can then be completely implemented by the designer.

=== CRC Design Assistant ===

The CRC Design assistant is a freely available software tool that was developed to make the CRC design process easy for students. The system consists of a simple Access database and a set of classes. The database stores the design information for the classes, responsibilities, collaborations, contracts, subsystems, users, and documentation.

[[File:crcda.jpg|center|x300px|CRC Design Assistant]]

Some of the important features of this tool are:

*The CRC view has index cards scattered around the workspace. It uses drag-and-drop to make changes to a design. Dragging one card into another automatically makes changes to both the classes. This ensures that changes in the design are consistent.
*The CRC view also makes identifying classes with too many responsibilities easier and also helps in identifying classes that are too interconnected with the rest of the system.
*The tool provides automatic documentation for the application design. The document is in rich text format (RTF) which can be opened with Microsoft Word or WordPerfect.
*It generates comma separated variable (CSV) files that can be opened with Microsoft Visio to create CRC diagrams and object diagrams.
*Lines are drawn to represent collaborations between classes thus making it easy to visualize the extent of coupling in the system.
*Allows the designer to view the design at different levels of complexity by providing support for subsystem abstraction and grouping classes performing related tasks into a subsystem.
*It allows us to handle the growth in workspace by providing an option to print the CRC cards from the database and use the traditional approach and update the database after a work session. We could also use a projector or an electronic whiteboard for the same.

=== Visual Paradigm for UML ===

Visual Paradigm for UML is a CASE tool for UML diagrams. It supports thirteen types of diagrams.Type of diagram can be selected from Diagram navigator. The option to select CRC card diagram is found under requirements capturing tab.Selecting a new CRC card diagram opens up a new diagram toolbar. We can create cards by selecting CRC Card from diagram tool. A new CRC card appears on screen. The properties have to be edited. We can edit Card name (class name), Super classes, sub classes, its attributes, its responsibilities and its collaborators. Attributes and responsibilities may be added by right clicking on attributes or responsibilities heading and click on add attribute or responsibility. Name of attribute and description can be entered and while entering responsibility Name and its collaborator are entered.

{|
|[[File:VPadd.png|x300px]]
|[[File:VPattr.png|x300px]]
|}

=== Easy CRC ===

EasyCRC combines CRC cards and sequence diagrams. It is originally developed to teach Object oriented paradigm. Most of UML tools don’t include CRC cards and diagrams which give conceptual view of the system rather they focus more on implementation view of the system. EasyCRC is the only tool that focuses on CRC cards and scenarios. If any changes occur to sequence diagrams we can make changes to CRC diagrams as well.
It also provides a text editor where the description can be copy pasted and the tool picks out the noun in the description and lists them. We can select the most appropriate nouns from the list and add them to the noun list. We can also select the words that were not listed by the tool by highlighting the word and adding it to noun list.There are two ways to update the responsibilities and collaborators in CRC diagram. First one is we enter all the values manually. The other method is to draw the sequence diagrams first and from these diagrams the responsibilities and collaborators of a class would be identified and updated.

=== Interactive 3D CRC Cards (Flying Circus) ===

In general 2D diagrams, it is difficult to see the entire diagram and its collaborators. This restricts the process of understanding the diagram and coming up with new collaborators. To avoid these a CRC card diagram can be drawn in a 3D space. Flying Circus is an automated 3D tool that aids the technique of CRC card design. CRC cards can be created, modified and placed in a 3D environment. The collaborations between the classes can be shown by links between the classes. Cards can be of different sizes, can use different colors and have comments included in it. Different colors make the easily visible however small the card may be. Flying circus is built out of open source projects like OpenSceneGraph(OSG), libsigc++, Flex etc. Flying circus provides functionality like creating CRC card, deleting a CRC card, collaborators update, change of information on CRC card, change of properties of CRC cards, 3D Manipulators to position it at a desired place in 3D space.

[[File:flying3D.png|center|x300px]]

=== Merobase Component Finder ===

It is an online software search engine. It supports simple text based search , interface search , module lookup. The software can be searched and reused. The query is searched in various sources like SourceForge etc. Merobase allows user to define a CRC card and searches its database for matching components and displays it to user. He can reuse the cards and software associated with it.
[[File:MeroBase.png|center|x300px]]

=== Software Ideas Modeler ===

Software Ideas Modeler is a light weight tool that supports 14 types of UML diagrams. On starting the tool it shows all the 14 type of diagrams it supports and asks to choose one among them. After selecting CRC diagram, a diagram toolbox is opened. From there we can select a new CRC card or a link and few other shapes are also provided. When a new CRC card is added, the name can be changed by clicking the name box. The propertied can be edited by double clicking the crc card. This opens up a property pop up box. All the required details can be filled up. At the bottom of CRC a 2 plus symbols is green color are provided. One is to add collaborator and the other one is to add responsibility. A comment button is also provided. All CRC cards can be created and collaborating cards can be linked using a link from diagram tool box.

{|
|[[File:SM1.png|x300px]]
|[[File:SM2.png|x300px]]
|}

CSC/ECE 517 Fall 2011/ch4 4i js

2011-10-21T00:22:47Z

Sgade: /* Quick CRC */

== Introduction ==

== CRC CARDS ==
Classes, Responsibilities, and Collaborations (CRC) is a design method focused on creating highly cohesive and modular systems. Classes represent the real world entities. They have responsibilities – data and actions the class has to support. These responsibilities can be filled by the class itself or may collaborate with other classes to fulfill it.
CRC cards are 3X5 index cards one for each class. Each has a name and has two columns one for responsibilities and one for collaborators. We can write attributes and description on back of the card.
CRC cards help visualize the design and design can be easily modified by just replacing few cards. These can be useful throughout the life cycle and provides a basis for formal analysis and design methodologies.

=== Creating CRC Cards ===

CRC Cards help in getting the design right. CRC cards are generated as follows:
• Discover Classes
• Determine Responsibilities of each class
• Describe relationship among each class.

'''Discover Classes:'''The nouns in requirement document translate to classes. We enforce certain rules while choosing classes. Identified Class is a singular noun or one that does not have functionality as some other class or is not simply a primitive type.

'''Determine Responsibilities:''' Responsibilities are the things that class knows or can do. Verbs in requirements document translate to responsibilities.

'''Describe Collaborators:''' Class might need other classes to fulfill certain responsibilities. Those classes can be identified as the collaborators for this class.

{|
|[[File:crccardlayout.jpg|x150px]]
|[[File:CRCCard.jpg|x150px]]
|}

 
The above CRC card describes the class Shopping Cart. A shopping cart must be able to items and remove items form it so they become responsibilities of that class. It has to collaborate with Product Catalog to add and remove items so Product Catalog becomes collaborator to Shopping Cart

=== Disadvantages of Paper CRC cards ===
*Modification of data in hand written cards is difficult.
*The information on cards needs to be transferred into an electronic medium in order to be used by software development tools.
*As the size of the project grows it’s difficult to maintain CRC cards.
*Difficult to communicate between teams.
*Time consuming.

=== Advantages of a CRC card tool ===
*Easy to maintain cards even as project grows in size.
*It can graphically illustrate relationship between cards.
*New cards can be defined for undefined super classes, subclasses etc.
*Information can be easily entered, updated, deleted.
*Information can be verified easily.
*When renaming a card information on other cards is easily updated.
*Easy to communicate these electronic cards between teams

==CRC Card Tools==

=== Quick CRC ===

QuickCRC is a commercial tool developed by Excel Software for designing object-oriented software. It can be used on Mac OS X or Windows.The process of designing a program using QuickCRC involves creating a card for each class, establishing relationships, assigning responsibilities and attributes, defining and simulating scenarios, checking the model for errors and illustrating interesting relationships between objects.

[[File:quickcrc.jpg|center|x300px|Quick CRC Tool]]

A few features supported by this tool are:
*Super and subclasses can be added by selecting from a pop up list of existing cards or by typing the name.
*Provides namespace support for partitioning the cards into different functional areas which can be used while listing specifications, printing cards or exporting information to other tools.
*It can generate the inheritance graphs form the information on the CRC cards.
*Linking cards and scenarios to foreign documents is made easy and thus they can be easily accessed with a single click of the mouse.
*Allows the creation and simulation of scenarios which allows the early identification and correction of bugs.
*The designer can show the attribute access of each card responsibility. QuickCRC automatically graphs the attribute access to highlight attribute usage and incomplete areas of the design and thus allows in locating design problems.
*Information can be imported from other development tools and thus we can generate CRC cards from source code with WinTranslator or MacTranslator.
*Information can be exported to other development tools as the CRC cards can be exported to MacA&D, WinA&D or QuickUML to auto-generate UML class diagrams.
*It can generate a text or HTML coding specification, generate cards, attributes and responsibilities from selected words in a text file or selectively print CRC cards for a peer review. Design work is saved as an XML file.

=== ECoDE (Ectropic Collaborative Design Environment) ===

The Ectropic Collaborative Design Environment, ECoDE, is a development tool designed to capture two key components of Ectropic design: Collaborations (CRC Cards) and Scenarios. ECoDE includes a graphical user interface targeting novice software designers and attempts to present an environment that couples the flexible and modular structure of well-designed object-oriented software and perspicuity of functionally organized software.The main interface called the Ectropic Design Navigator consists of two tools namely The CRC Card Navigator and the Scenarios Navigator. The design process consists of three phases:

Analysis mode: This phase involves identifying and analyzing the program goals, identifying candidate classes to meet them, determining the responsibilities and distributing them among the candidate classes. It also involves creating scenarios for identifying the required responsibilities and building Scenarios from a sequence of CRC Card Responsibility pairs.

Design mode: This phase aims at designing a complete and implementable design. It involves reviewing each CRC card and assigning a corresponding method to each responsibility assigned to the card. In this mode the designer can create, categorize, and describe methods and match them with specific responsibilities apart from the tasks available in the analysis phase.

Program Phase: In this phase the tool checks all the CRC cards and makes sure that all the responsibilities have been assigned their corresponding methods. This allows in fixing deficiencies. It also provides the ability to convert CRC cards to actual Classes after which it asks the designer to provide attributes for the class and generates source code stubs which can then be completely implemented by the designer.

=== CRC Design Assistant ===

The CRC Design assistant is a freely available software tool that was developed to make the CRC design process easy for students. The system consists of a simple Access database and a set of classes. The database stores the design information for the classes, responsibilities, collaborations, contracts, subsystems, users, and documentation.

Some of the important features of this tool are:

*The CRC view has index cards scattered around the workspace. It uses drag-and-drop to make changes to a design. Dragging one card into another automatically makes changes to both the classes. This ensures that changes in the design are consistent.
*The CRC view also makes identifying classes with too many responsibilities easier and also helps in identifying classes that are too interconnected with the rest of the system.
*The tool provides automatic documentation for the application design. The document is in rich text format (RTF) which can be opened with Microsoft Word or WordPerfect.
*It generates comma separated variable (CSV) files that can be opened with Microsoft Visio to create CRC diagrams and object diagrams.
*Lines are drawn to represent collaborations between classes thus making it easy to visualize the extent of coupling in the system.
*Allows the designer to view the design at different levels of complexity by providing support for subsystem abstraction and grouping classes performing related tasks into a subsystem.
*It allows us to handle the growth in workspace by providing an option to print the CRC cards from the database and use the traditional approach and update the database after a work session. We could also use a projector or an electronic whiteboard for the same.

=== Visual Paradigm for UML ===

Visual Paradigm for UML is a CASE tool for UML diagrams. It supports thirteen types of diagrams.Type of diagram can be selected from Diagram navigator. The option to select CRC card diagram is found under requirements capturing tab.Selecting a new CRC card diagram opens up a new diagram toolbar. We can create cards by selecting CRC Card from diagram tool. A new CRC card appears on screen. The properties have to be edited. We can edit Card name (class name), Super classes, sub classes, its attributes, its responsibilities and its collaborators. Attributes and responsibilities may be added by right clicking on attributes or responsibilities heading and click on add attribute or responsibility. Name of attribute and description can be entered and while entering responsibility Name and its collaborator are entered.

{|
|[[File:VPadd.png|x300px]]
|[[File:VPattr.png|x300px]]
|}

=== Easy CRC ===

EasyCRC combines CRC cards and sequence diagrams. It is originally developed to teach Object oriented paradigm. Most of UML tools don’t include CRC cards and diagrams which give conceptual view of the system rather they focus more on implementation view of the system. EasyCRC is the only tool that focuses on CRC cards and scenarios. If any changes occur to sequence diagrams we can make changes to CRC diagrams as well.
It also provides a text editor where the description can be copy pasted and the tool picks out the noun in the description and lists them. We can select the most appropriate nouns from the list and add them to the noun list. We can also select the words that were not listed by the tool by highlighting the word and adding it to noun list.There are two ways to update the responsibilities and collaborators in CRC diagram. First one is we enter all the values manually. The other method is to draw the sequence diagrams first and from these diagrams the responsibilities and collaborators of a class would be identified and updated.

=== Interactive 3D CRC Cards (Flying Circus) ===

In general 2D diagrams, it is difficult to see the entire diagram and its collaborators. This restricts the process of understanding the diagram and coming up with new collaborators. To avoid these a CRC card diagram can be drawn in a 3D space. Flying Circus is an automated 3D tool that aids the technique of CRC card design. CRC cards can be created, modified and placed in a 3D environment. The collaborations between the classes can be shown by links between the classes. Cards can be of different sizes, can use different colors and have comments included in it. Different colors make the easily visible however small the card may be. Flying circus is built out of open source projects like OpenSceneGraph(OSG), libsigc++, Flex etc. Flying circus provides functionality like creating CRC card, deleting a CRC card, collaborators update, change of information on CRC card, change of properties of CRC cards, 3D Manipulators to position it at a desired place in 3D space.

[[File:flying3D.png|center|x300px]]

=== Merobase Component Finder ===

It is an online software search engine. It supports simple text based search , interface search , module lookup. The software can be searched and reused. The query is searched in various sources like SourceForge etc. Merobase allows user to define a CRC card and searches its database for matching components and displays it to user. He can reuse the cards and software associated with it.
[[File:MeroBase.png|center|x300px]]

=== Software Ideas Modeler ===

Software Ideas Modeler is a light weight tool that supports 14 types of UML diagrams. On starting the tool it shows all the 14 type of diagrams it supports and asks to choose one among them. After selecting CRC diagram, a diagram toolbox is opened. From there we can select a new CRC card or a link and few other shapes are also provided. When a new CRC card is added, the name can be changed by clicking the name box. The propertied can be edited by double clicking the crc card. This opens up a property pop up box. All the required details can be filled up. At the bottom of CRC a 2 plus symbols is green color are provided. One is to add collaborator and the other one is to add responsibility. A comment button is also provided. All CRC cards can be created and collaborating cards can be linked using a link from diagram tool box.

File:Quickcrc.jpg

2011-10-21T00:22:09Z

Sgade:

CSC/ECE 517 Fall 2011/ch4 4i js

2011-10-21T00:21:26Z

Sgade: /* Quick CRC */

== Introduction ==

== CRC CARDS ==
Classes, Responsibilities, and Collaborations (CRC) is a design method focused on creating highly cohesive and modular systems. Classes represent the real world entities. They have responsibilities – data and actions the class has to support. These responsibilities can be filled by the class itself or may collaborate with other classes to fulfill it.
CRC cards are 3X5 index cards one for each class. Each has a name and has two columns one for responsibilities and one for collaborators. We can write attributes and description on back of the card.
CRC cards help visualize the design and design can be easily modified by just replacing few cards. These can be useful throughout the life cycle and provides a basis for formal analysis and design methodologies.

=== Creating CRC Cards ===

CRC Cards help in getting the design right. CRC cards are generated as follows:
• Discover Classes
• Determine Responsibilities of each class
• Describe relationship among each class.

'''Discover Classes:'''The nouns in requirement document translate to classes. We enforce certain rules while choosing classes. Identified Class is a singular noun or one that does not have functionality as some other class or is not simply a primitive type.

'''Determine Responsibilities:''' Responsibilities are the things that class knows or can do. Verbs in requirements document translate to responsibilities.

'''Describe Collaborators:''' Class might need other classes to fulfill certain responsibilities. Those classes can be identified as the collaborators for this class.

{|
|[[File:crccardlayout.jpg|x150px]]
|[[File:CRCCard.jpg|x150px]]
|}

 
The above CRC card describes the class Shopping Cart. A shopping cart must be able to items and remove items form it so they become responsibilities of that class. It has to collaborate with Product Catalog to add and remove items so Product Catalog becomes collaborator to Shopping Cart

=== Disadvantages of Paper CRC cards ===
*Modification of data in hand written cards is difficult.
*The information on cards needs to be transferred into an electronic medium in order to be used by software development tools.
*As the size of the project grows it’s difficult to maintain CRC cards.
*Difficult to communicate between teams.
*Time consuming.

=== Advantages of a CRC card tool ===
*Easy to maintain cards even as project grows in size.
*It can graphically illustrate relationship between cards.
*New cards can be defined for undefined super classes, subclasses etc.
*Information can be easily entered, updated, deleted.
*Information can be verified easily.
*When renaming a card information on other cards is easily updated.
*Easy to communicate these electronic cards between teams

==CRC Card Tools==

=== Quick CRC ===

QuickCRC is a commercial tool developed by Excel Software for designing object-oriented software. It can be used on Mac OS X or Windows.The process of designing a program using QuickCRC involves creating a card for each class, establishing relationships, assigning responsibilities and attributes, defining and simulating scenarios, checking the model for errors and illustrating interesting relationships between objects.

[[File:quickcrc.jpg|center|300px|Quick CRC Tool]]

A few features supported by this tool are:
*Super and subclasses can be added by selecting from a pop up list of existing cards or by typing the name.
*Provides namespace support for partitioning the cards into different functional areas which can be used while listing specifications, printing cards or exporting information to other tools.
*It can generate the inheritance graphs form the information on the CRC cards.
*Linking cards and scenarios to foreign documents is made easy and thus they can be easily accessed with a single click of the mouse.
*Allows the creation and simulation of scenarios which allows the early identification and correction of bugs.
*The designer can show the attribute access of each card responsibility. QuickCRC automatically graphs the attribute access to highlight attribute usage and incomplete areas of the design and thus allows in locating design problems.
*Information can be imported from other development tools and thus we can generate CRC cards from source code with WinTranslator or MacTranslator.
*Information can be exported to other development tools as the CRC cards can be exported to MacA&D, WinA&D or QuickUML to auto-generate UML class diagrams.
*It can generate a text or HTML coding specification, generate cards, attributes and responsibilities from selected words in a text file or selectively print CRC cards for a peer review. Design work is saved as an XML file.

=== ECoDE (Ectropic Collaborative Design Environment) ===

The Ectropic Collaborative Design Environment, ECoDE, is a development tool designed to capture two key components of Ectropic design: Collaborations (CRC Cards) and Scenarios. ECoDE includes a graphical user interface targeting novice software designers and attempts to present an environment that couples the flexible and modular structure of well-designed object-oriented software and perspicuity of functionally organized software.The main interface called the Ectropic Design Navigator consists of two tools namely The CRC Card Navigator and the Scenarios Navigator. The design process consists of three phases:

Analysis mode: This phase involves identifying and analyzing the program goals, identifying candidate classes to meet them, determining the responsibilities and distributing them among the candidate classes. It also involves creating scenarios for identifying the required responsibilities and building Scenarios from a sequence of CRC Card Responsibility pairs.

Design mode: This phase aims at designing a complete and implementable design. It involves reviewing each CRC card and assigning a corresponding method to each responsibility assigned to the card. In this mode the designer can create, categorize, and describe methods and match them with specific responsibilities apart from the tasks available in the analysis phase.

Program Phase: In this phase the tool checks all the CRC cards and makes sure that all the responsibilities have been assigned their corresponding methods. This allows in fixing deficiencies. It also provides the ability to convert CRC cards to actual Classes after which it asks the designer to provide attributes for the class and generates source code stubs which can then be completely implemented by the designer.

=== CRC Design Assistant ===

The CRC Design assistant is a freely available software tool that was developed to make the CRC design process easy for students. The system consists of a simple Access database and a set of classes. The database stores the design information for the classes, responsibilities, collaborations, contracts, subsystems, users, and documentation.

Some of the important features of this tool are:

*The CRC view has index cards scattered around the workspace. It uses drag-and-drop to make changes to a design. Dragging one card into another automatically makes changes to both the classes. This ensures that changes in the design are consistent.
*The CRC view also makes identifying classes with too many responsibilities easier and also helps in identifying classes that are too interconnected with the rest of the system.
*The tool provides automatic documentation for the application design. The document is in rich text format (RTF) which can be opened with Microsoft Word or WordPerfect.
*It generates comma separated variable (CSV) files that can be opened with Microsoft Visio to create CRC diagrams and object diagrams.
*Lines are drawn to represent collaborations between classes thus making it easy to visualize the extent of coupling in the system.
*Allows the designer to view the design at different levels of complexity by providing support for subsystem abstraction and grouping classes performing related tasks into a subsystem.
*It allows us to handle the growth in workspace by providing an option to print the CRC cards from the database and use the traditional approach and update the database after a work session. We could also use a projector or an electronic whiteboard for the same.

=== Visual Paradigm for UML ===

Visual Paradigm for UML is a CASE tool for UML diagrams. It supports thirteen types of diagrams.Type of diagram can be selected from Diagram navigator. The option to select CRC card diagram is found under requirements capturing tab.Selecting a new CRC card diagram opens up a new diagram toolbar. We can create cards by selecting CRC Card from diagram tool. A new CRC card appears on screen. The properties have to be edited. We can edit Card name (class name), Super classes, sub classes, its attributes, its responsibilities and its collaborators. Attributes and responsibilities may be added by right clicking on attributes or responsibilities heading and click on add attribute or responsibility. Name of attribute and description can be entered and while entering responsibility Name and its collaborator are entered.

{|
|[[File:VPadd.png|x300px]]
|[[File:VPattr.png|x300px]]
|}

=== Easy CRC ===

EasyCRC combines CRC cards and sequence diagrams. It is originally developed to teach Object oriented paradigm. Most of UML tools don’t include CRC cards and diagrams which give conceptual view of the system rather they focus more on implementation view of the system. EasyCRC is the only tool that focuses on CRC cards and scenarios. If any changes occur to sequence diagrams we can make changes to CRC diagrams as well.
It also provides a text editor where the description can be copy pasted and the tool picks out the noun in the description and lists them. We can select the most appropriate nouns from the list and add them to the noun list. We can also select the words that were not listed by the tool by highlighting the word and adding it to noun list.There are two ways to update the responsibilities and collaborators in CRC diagram. First one is we enter all the values manually. The other method is to draw the sequence diagrams first and from these diagrams the responsibilities and collaborators of a class would be identified and updated.

=== Interactive 3D CRC Cards (Flying Circus) ===

In general 2D diagrams, it is difficult to see the entire diagram and its collaborators. This restricts the process of understanding the diagram and coming up with new collaborators. To avoid these a CRC card diagram can be drawn in a 3D space. Flying Circus is an automated 3D tool that aids the technique of CRC card design. CRC cards can be created, modified and placed in a 3D environment. The collaborations between the classes can be shown by links between the classes. Cards can be of different sizes, can use different colors and have comments included in it. Different colors make the easily visible however small the card may be. Flying circus is built out of open source projects like OpenSceneGraph(OSG), libsigc++, Flex etc. Flying circus provides functionality like creating CRC card, deleting a CRC card, collaborators update, change of information on CRC card, change of properties of CRC cards, 3D Manipulators to position it at a desired place in 3D space.

[[File:flying3D.png|center|x300px]]

=== Merobase Component Finder ===

It is an online software search engine. It supports simple text based search , interface search , module lookup. The software can be searched and reused. The query is searched in various sources like SourceForge etc. Merobase allows user to define a CRC card and searches its database for matching components and displays it to user. He can reuse the cards and software associated with it.
[[File:MeroBase.png|center|x300px]]

=== Software Ideas Modeler ===

Software Ideas Modeler is a light weight tool that supports 14 types of UML diagrams. On starting the tool it shows all the 14 type of diagrams it supports and asks to choose one among them. After selecting CRC diagram, a diagram toolbox is opened. From there we can select a new CRC card or a link and few other shapes are also provided. When a new CRC card is added, the name can be changed by clicking the name box. The propertied can be edited by double clicking the crc card. This opens up a property pop up box. All the required details can be filled up. At the bottom of CRC a 2 plus symbols is green color are provided. One is to add collaborator and the other one is to add responsibility. A comment button is also provided. All CRC cards can be created and collaborating cards can be linked using a link from diagram tool box.

File:Quickcrc.gif

2011-10-21T00:18:24Z

Sgade:

CSC/ECE 517 Fall 2011/ch4 4i js

2011-10-21T00:17:56Z

Sgade: /* Quick CRC */

== Introduction ==

== CRC CARDS ==
Classes, Responsibilities, and Collaborations (CRC) is a design method focused on creating highly cohesive and modular systems. Classes represent the real world entities. They have responsibilities – data and actions the class has to support. These responsibilities can be filled by the class itself or may collaborate with other classes to fulfill it.
CRC cards are 3X5 index cards one for each class. Each has a name and has two columns one for responsibilities and one for collaborators. We can write attributes and description on back of the card.
CRC cards help visualize the design and design can be easily modified by just replacing few cards. These can be useful throughout the life cycle and provides a basis for formal analysis and design methodologies.

=== Creating CRC Cards ===

CRC Cards help in getting the design right. CRC cards are generated as follows:
• Discover Classes
• Determine Responsibilities of each class
• Describe relationship among each class.

'''Discover Classes:'''The nouns in requirement document translate to classes. We enforce certain rules while choosing classes. Identified Class is a singular noun or one that does not have functionality as some other class or is not simply a primitive type.

'''Determine Responsibilities:''' Responsibilities are the things that class knows or can do. Verbs in requirements document translate to responsibilities.

'''Describe Collaborators:''' Class might need other classes to fulfill certain responsibilities. Those classes can be identified as the collaborators for this class.

{|
|[[File:crccardlayout.jpg|x150px]]
|[[File:CRCCard.jpg|x150px]]
|}

 
The above CRC card describes the class Shopping Cart. A shopping cart must be able to items and remove items form it so they become responsibilities of that class. It has to collaborate with Product Catalog to add and remove items so Product Catalog becomes collaborator to Shopping Cart

=== Disadvantages of Paper CRC cards ===
*Modification of data in hand written cards is difficult.
*The information on cards needs to be transferred into an electronic medium in order to be used by software development tools.
*As the size of the project grows it’s difficult to maintain CRC cards.
*Difficult to communicate between teams.
*Time consuming.

=== Advantages of a CRC card tool ===
*Easy to maintain cards even as project grows in size.
*It can graphically illustrate relationship between cards.
*New cards can be defined for undefined super classes, subclasses etc.
*Information can be easily entered, updated, deleted.
*Information can be verified easily.
*When renaming a card information on other cards is easily updated.
*Easy to communicate these electronic cards between teams

==CRC Card Tools==

=== Quick CRC ===

QuickCRC is a commercial tool developed by Excel Software for designing object-oriented software. It can be used on Mac OS X or Windows.The process of designing a program using QuickCRC involves creating a card for each class, establishing relationships, assigning responsibilities and attributes, defining and simulating scenarios, checking the model for errors and illustrating interesting relationships between objects.

[[File:quickcrc.gif|center|300px|Quick CRC Tool]]

A few features supported by this tool are:
*Super and subclasses can be added by selecting from a pop up list of existing cards or by typing the name.
*Provides namespace support for partitioning the cards into different functional areas which can be used while listing specifications, printing cards or exporting information to other tools.
*It can generate the inheritance graphs form the information on the CRC cards.
*Linking cards and scenarios to foreign documents is made easy and thus they can be easily accessed with a single click of the mouse.
*Allows the creation and simulation of scenarios which allows the early identification and correction of bugs.
*The designer can show the attribute access of each card responsibility. QuickCRC automatically graphs the attribute access to highlight attribute usage and incomplete areas of the design and thus allows in locating design problems.
*Information can be imported from other development tools and thus we can generate CRC cards from source code with WinTranslator or MacTranslator.
*Information can be exported to other development tools as the CRC cards can be exported to MacA&D, WinA&D or QuickUML to auto-generate UML class diagrams.
*It can generate a text or HTML coding specification, generate cards, attributes and responsibilities from selected words in a text file or selectively print CRC cards for a peer review. Design work is saved as an XML file.

=== ECoDE (Ectropic Collaborative Design Environment) ===

The Ectropic Collaborative Design Environment, ECoDE, is a development tool designed to capture two key components of Ectropic design: Collaborations (CRC Cards) and Scenarios. ECoDE includes a graphical user interface targeting novice software designers and attempts to present an environment that couples the flexible and modular structure of well-designed object-oriented software and perspicuity of functionally organized software.The main interface called the Ectropic Design Navigator consists of two tools namely The CRC Card Navigator and the Scenarios Navigator. The design process consists of three phases:

Analysis mode: This phase involves identifying and analyzing the program goals, identifying candidate classes to meet them, determining the responsibilities and distributing them among the candidate classes. It also involves creating scenarios for identifying the required responsibilities and building Scenarios from a sequence of CRC Card Responsibility pairs.

Design mode: This phase aims at designing a complete and implementable design. It involves reviewing each CRC card and assigning a corresponding method to each responsibility assigned to the card. In this mode the designer can create, categorize, and describe methods and match them with specific responsibilities apart from the tasks available in the analysis phase.

Program Phase: In this phase the tool checks all the CRC cards and makes sure that all the responsibilities have been assigned their corresponding methods. This allows in fixing deficiencies. It also provides the ability to convert CRC cards to actual Classes after which it asks the designer to provide attributes for the class and generates source code stubs which can then be completely implemented by the designer.

=== CRC Design Assistant ===

The CRC Design assistant is a freely available software tool that was developed to make the CRC design process easy for students. The system consists of a simple Access database and a set of classes. The database stores the design information for the classes, responsibilities, collaborations, contracts, subsystems, users, and documentation.

Some of the important features of this tool are:

*The CRC view has index cards scattered around the workspace. It uses drag-and-drop to make changes to a design. Dragging one card into another automatically makes changes to both the classes. This ensures that changes in the design are consistent.
*The CRC view also makes identifying classes with too many responsibilities easier and also helps in identifying classes that are too interconnected with the rest of the system.
*The tool provides automatic documentation for the application design. The document is in rich text format (RTF) which can be opened with Microsoft Word or WordPerfect.
*It generates comma separated variable (CSV) files that can be opened with Microsoft Visio to create CRC diagrams and object diagrams.
*Lines are drawn to represent collaborations between classes thus making it easy to visualize the extent of coupling in the system.
*Allows the designer to view the design at different levels of complexity by providing support for subsystem abstraction and grouping classes performing related tasks into a subsystem.
*It allows us to handle the growth in workspace by providing an option to print the CRC cards from the database and use the traditional approach and update the database after a work session. We could also use a projector or an electronic whiteboard for the same.

=== Visual Paradigm for UML ===

Visual Paradigm for UML is a CASE tool for UML diagrams. It supports thirteen types of diagrams.Type of diagram can be selected from Diagram navigator. The option to select CRC card diagram is found under requirements capturing tab.Selecting a new CRC card diagram opens up a new diagram toolbar. We can create cards by selecting CRC Card from diagram tool. A new CRC card appears on screen. The properties have to be edited. We can edit Card name (class name), Super classes, sub classes, its attributes, its responsibilities and its collaborators. Attributes and responsibilities may be added by right clicking on attributes or responsibilities heading and click on add attribute or responsibility. Name of attribute and description can be entered and while entering responsibility Name and its collaborator are entered.

{|
|[[File:VPadd.png|x300px]]
|[[File:VPattr.png|x300px]]
|}

=== Easy CRC ===

EasyCRC combines CRC cards and sequence diagrams. It is originally developed to teach Object oriented paradigm. Most of UML tools don’t include CRC cards and diagrams which give conceptual view of the system rather they focus more on implementation view of the system. EasyCRC is the only tool that focuses on CRC cards and scenarios. If any changes occur to sequence diagrams we can make changes to CRC diagrams as well.
It also provides a text editor where the description can be copy pasted and the tool picks out the noun in the description and lists them. We can select the most appropriate nouns from the list and add them to the noun list. We can also select the words that were not listed by the tool by highlighting the word and adding it to noun list.There are two ways to update the responsibilities and collaborators in CRC diagram. First one is we enter all the values manually. The other method is to draw the sequence diagrams first and from these diagrams the responsibilities and collaborators of a class would be identified and updated.

=== Interactive 3D CRC Cards (Flying Circus) ===

In general 2D diagrams, it is difficult to see the entire diagram and its collaborators. This restricts the process of understanding the diagram and coming up with new collaborators. To avoid these a CRC card diagram can be drawn in a 3D space. Flying Circus is an automated 3D tool that aids the technique of CRC card design. CRC cards can be created, modified and placed in a 3D environment. The collaborations between the classes can be shown by links between the classes. Cards can be of different sizes, can use different colors and have comments included in it. Different colors make the easily visible however small the card may be. Flying circus is built out of open source projects like OpenSceneGraph(OSG), libsigc++, Flex etc. Flying circus provides functionality like creating CRC card, deleting a CRC card, collaborators update, change of information on CRC card, change of properties of CRC cards, 3D Manipulators to position it at a desired place in 3D space.

[[File:flying3D.png|center|x300px]]

=== Merobase Component Finder ===

It is an online software search engine. It supports simple text based search , interface search , module lookup. The software can be searched and reused. The query is searched in various sources like SourceForge etc. Merobase allows user to define a CRC card and searches its database for matching components and displays it to user. He can reuse the cards and software associated with it.

=== Software Ideas Modeler ===

Software Ideas Modeler is a light weight tool that supports 14 types of UML diagrams. On starting the tool it shows all the 14 type of diagrams it supports and asks to choose one among them. After selecting CRC diagram, a diagram toolbox is opened. From there we can select a new CRC card or a link and few other shapes are also provided. When a new CRC card is added, the name can be changed by clicking the name box. The propertied can be edited by double clicking the crc card. This opens up a property pop up box. All the required details can be filled up. At the bottom of CRC a 2 plus symbols is green color are provided. One is to add collaborator and the other one is to add responsibility. A comment button is also provided. All CRC cards can be created and collaborating cards can be linked using a link from diagram tool box.

CSC/ECE 517 Fall 2011/ch4 4i js

2011-10-21T00:17:07Z

Sgade: /* Quick CRC */

== Introduction ==

== CRC CARDS ==
Classes, Responsibilities, and Collaborations (CRC) is a design method focused on creating highly cohesive and modular systems. Classes represent the real world entities. They have responsibilities – data and actions the class has to support. These responsibilities can be filled by the class itself or may collaborate with other classes to fulfill it.
CRC cards are 3X5 index cards one for each class. Each has a name and has two columns one for responsibilities and one for collaborators. We can write attributes and description on back of the card.
CRC cards help visualize the design and design can be easily modified by just replacing few cards. These can be useful throughout the life cycle and provides a basis for formal analysis and design methodologies.

=== Creating CRC Cards ===

CRC Cards help in getting the design right. CRC cards are generated as follows:
• Discover Classes
• Determine Responsibilities of each class
• Describe relationship among each class.

'''Discover Classes:'''The nouns in requirement document translate to classes. We enforce certain rules while choosing classes. Identified Class is a singular noun or one that does not have functionality as some other class or is not simply a primitive type.

'''Determine Responsibilities:''' Responsibilities are the things that class knows or can do. Verbs in requirements document translate to responsibilities.

'''Describe Collaborators:''' Class might need other classes to fulfill certain responsibilities. Those classes can be identified as the collaborators for this class.

{|
|[[File:crccardlayout.jpg|x150px]]
|[[File:CRCCard.jpg|x150px]]
|}

 
The above CRC card describes the class Shopping Cart. A shopping cart must be able to items and remove items form it so they become responsibilities of that class. It has to collaborate with Product Catalog to add and remove items so Product Catalog becomes collaborator to Shopping Cart

=== Disadvantages of Paper CRC cards ===
*Modification of data in hand written cards is difficult.
*The information on cards needs to be transferred into an electronic medium in order to be used by software development tools.
*As the size of the project grows it’s difficult to maintain CRC cards.
*Difficult to communicate between teams.
*Time consuming.

=== Advantages of a CRC card tool ===
*Easy to maintain cards even as project grows in size.
*It can graphically illustrate relationship between cards.
*New cards can be defined for undefined super classes, subclasses etc.
*Information can be easily entered, updated, deleted.
*Information can be verified easily.
*When renaming a card information on other cards is easily updated.
*Easy to communicate these electronic cards between teams

==CRC Card Tools==

=== Quick CRC ===

QuickCRC is a commercial tool developed by Excel Software for designing object-oriented software. It can be used on Mac OS X or Windows.The process of designing a program using QuickCRC involves creating a card for each class, establishing relationships, assigning responsibilities and attributes, defining and simulating scenarios, checking the model for errors and illustrating interesting relationships between objects.

[[File:quickcrc.gif|center|300px]]

A few features supported by this tool are:
*Super and subclasses can be added by selecting from a pop up list of existing cards or by typing the name.
*Provides namespace support for partitioning the cards into different functional areas which can be used while listing specifications, printing cards or exporting information to other tools.
*It can generate the inheritance graphs form the information on the CRC cards.
*Linking cards and scenarios to foreign documents is made easy and thus they can be easily accessed with a single click of the mouse.
*Allows the creation and simulation of scenarios which allows the early identification and correction of bugs.
*The designer can show the attribute access of each card responsibility. QuickCRC automatically graphs the attribute access to highlight attribute usage and incomplete areas of the design and thus allows in locating design problems.
*Information can be imported from other development tools and thus we can generate CRC cards from source code with WinTranslator or MacTranslator.
*Information can be exported to other development tools as the CRC cards can be exported to MacA&D, WinA&D or QuickUML to auto-generate UML class diagrams.
*It can generate a text or HTML coding specification, generate cards, attributes and responsibilities from selected words in a text file or selectively print CRC cards for a peer review. Design work is saved as an XML file.

=== ECoDE (Ectropic Collaborative Design Environment) ===

The Ectropic Collaborative Design Environment, ECoDE, is a development tool designed to capture two key components of Ectropic design: Collaborations (CRC Cards) and Scenarios. ECoDE includes a graphical user interface targeting novice software designers and attempts to present an environment that couples the flexible and modular structure of well-designed object-oriented software and perspicuity of functionally organized software.The main interface called the Ectropic Design Navigator consists of two tools namely The CRC Card Navigator and the Scenarios Navigator. The design process consists of three phases:

Analysis mode: This phase involves identifying and analyzing the program goals, identifying candidate classes to meet them, determining the responsibilities and distributing them among the candidate classes. It also involves creating scenarios for identifying the required responsibilities and building Scenarios from a sequence of CRC Card Responsibility pairs.

Design mode: This phase aims at designing a complete and implementable design. It involves reviewing each CRC card and assigning a corresponding method to each responsibility assigned to the card. In this mode the designer can create, categorize, and describe methods and match them with specific responsibilities apart from the tasks available in the analysis phase.

Program Phase: In this phase the tool checks all the CRC cards and makes sure that all the responsibilities have been assigned their corresponding methods. This allows in fixing deficiencies. It also provides the ability to convert CRC cards to actual Classes after which it asks the designer to provide attributes for the class and generates source code stubs which can then be completely implemented by the designer.

=== CRC Design Assistant ===

The CRC Design assistant is a freely available software tool that was developed to make the CRC design process easy for students. The system consists of a simple Access database and a set of classes. The database stores the design information for the classes, responsibilities, collaborations, contracts, subsystems, users, and documentation.

Some of the important features of this tool are:

*The CRC view has index cards scattered around the workspace. It uses drag-and-drop to make changes to a design. Dragging one card into another automatically makes changes to both the classes. This ensures that changes in the design are consistent.
*The CRC view also makes identifying classes with too many responsibilities easier and also helps in identifying classes that are too interconnected with the rest of the system.
*The tool provides automatic documentation for the application design. The document is in rich text format (RTF) which can be opened with Microsoft Word or WordPerfect.
*It generates comma separated variable (CSV) files that can be opened with Microsoft Visio to create CRC diagrams and object diagrams.
*Lines are drawn to represent collaborations between classes thus making it easy to visualize the extent of coupling in the system.
*Allows the designer to view the design at different levels of complexity by providing support for subsystem abstraction and grouping classes performing related tasks into a subsystem.
*It allows us to handle the growth in workspace by providing an option to print the CRC cards from the database and use the traditional approach and update the database after a work session. We could also use a projector or an electronic whiteboard for the same.

=== Visual Paradigm for UML ===

Visual Paradigm for UML is a CASE tool for UML diagrams. It supports thirteen types of diagrams.Type of diagram can be selected from Diagram navigator. The option to select CRC card diagram is found under requirements capturing tab.Selecting a new CRC card diagram opens up a new diagram toolbar. We can create cards by selecting CRC Card from diagram tool. A new CRC card appears on screen. The properties have to be edited. We can edit Card name (class name), Super classes, sub classes, its attributes, its responsibilities and its collaborators. Attributes and responsibilities may be added by right clicking on attributes or responsibilities heading and click on add attribute or responsibility. Name of attribute and description can be entered and while entering responsibility Name and its collaborator are entered.

{|
|[[File:VPadd.png|x300px]]
|[[File:VPattr.png|x300px]]
|}

=== Easy CRC ===

EasyCRC combines CRC cards and sequence diagrams. It is originally developed to teach Object oriented paradigm. Most of UML tools don’t include CRC cards and diagrams which give conceptual view of the system rather they focus more on implementation view of the system. EasyCRC is the only tool that focuses on CRC cards and scenarios. If any changes occur to sequence diagrams we can make changes to CRC diagrams as well.
It also provides a text editor where the description can be copy pasted and the tool picks out the noun in the description and lists them. We can select the most appropriate nouns from the list and add them to the noun list. We can also select the words that were not listed by the tool by highlighting the word and adding it to noun list.There are two ways to update the responsibilities and collaborators in CRC diagram. First one is we enter all the values manually. The other method is to draw the sequence diagrams first and from these diagrams the responsibilities and collaborators of a class would be identified and updated.

=== Interactive 3D CRC Cards (Flying Circus) ===

In general 2D diagrams, it is difficult to see the entire diagram and its collaborators. This restricts the process of understanding the diagram and coming up with new collaborators. To avoid these a CRC card diagram can be drawn in a 3D space. Flying Circus is an automated 3D tool that aids the technique of CRC card design. CRC cards can be created, modified and placed in a 3D environment. The collaborations between the classes can be shown by links between the classes. Cards can be of different sizes, can use different colors and have comments included in it. Different colors make the easily visible however small the card may be. Flying circus is built out of open source projects like OpenSceneGraph(OSG), libsigc++, Flex etc. Flying circus provides functionalities like creating CRC card, deleting a CRC card, collaborators update, change of information on CRC card, change of properties of CRC cards, 3D Manipulators to position it at a desired place in 3D space.

[[File:flying3D.png]|x300px|center]

=== Merobase Component Finder ===

It is an online software search engine. It supports simple text based search , interface search , module lookup. The software can be searched and reused. The query is searched in various sources like SourceForge etc. Merobase allows user to define a CRC card and searches its database for matching components and displays it to user. He can reuse the cards and software associated with it.

=== Software Ideas Modeler ===

Software Ideas Modeler is a light weight tool that supports 14 types of UML diagrams. On starting the tool it shows all the 14 type of diagrams it supports and asks to choose one among them. After selecting CRC diagram, a diagram toolbox is opened. From there we can select a new CRC card or a link and few other shapes are also provided. When a new CRC card is added, the name can be changed by clicking the name box. The propertied can be edited by double clicking the crc card. This opens up a property pop up box. All the required details can be filled up. At the bottom of CRC a 2 plus symbols is green color are provided. One is to add collaborator and the other one is to add responsibility. A comment button is also provided. All CRC cards can be created and collaborating cards can be linked using a link from diagram tool box.

CSC/ECE 517 Fall 2011/ch4 4i js

2011-10-20T23:43:37Z

Sgade: Created page with "== Introduction == Classes, Responsibilities, and Collaborations (CRC) is a design method focused on creating highly cohesive and modular systems. Classes represent the real worl..."

== Introduction ==
Classes, Responsibilities, and Collaborations (CRC) is a design method focused on creating highly cohesive and modular systems. Classes represent the real world entities. They have responsibilities – data and actions the class has to support. These responsibilities can be filled by the class itself or may collaborate with other classes to fulfill it.
CRC cards are 3X5 index cards one for each class. Each has a name and has two columns one for responsibilities and one for collaborators. We can write attributes and description on back of the card.
CRC cards help visualize the design and design can be easily modified by just replacing few cards. These can be useful throughout the life cycle and provides a basis for formal analysis and design methodologies.

Disadvantages of Paper CRC cards:
*Modification of data in hand written cards is difficult.
*The information on cards needs to be transferred into an electronic medium in order to be used by software development tools.
*As the size of the project grows it’s difficult to maintain CRC cards.
*Difficult to communicate between teams.
*Time consuming.

Advantages of a CRC card tool:
*Easy to maintain cards even as project grows in size.
*It can graphically illustrate relationship between cards.
*New cards can be defined for undefined super classes, subclasses etc.
*Information can be easily entered, updated, deleted.
*Information can be verified easily.
*When renaming a card information on other cards is easily updated.
*Easy to communicate these electronic cards between teams

==CRC Card Tools==

=== Quick CRC ===

QuickCRC is a commercial tool developed by Excel Software for designing object-oriented software. It can be used on Mac OS X or Windows.The process of designing a program using QuickCRC involves creating a card for each class, establishing relationships, assigning responsibilities and attributes, defining and simulating scenarios, checking the model for errors and illustrating interesting relationships between objects.

A few features supported by this tool are:
*Super and subclasses can be added by selecting from a pop up list of existing cards or by typing the name.
*Provides namespace support for partitioning the cards into different functional areas which can be used while listing specifications, printing cards or exporting information to other tools.
*It can generate the inheritance graphs form the information on the CRC cards.
*Linking cards and scenarios to foreign documents is made easy and thus they can be easily accessed with a single click of the mouse.
*Allows the creation and simulation of scenarios which allows the early identification and correction of bugs.
*The designer can show the attribute access of each card responsibility. QuickCRC automatically graphs the attribute access to highlight attribute usage and incomplete areas of the design and thus allows in locating design problems.
*Information can be imported from other development tools and thus we can generate CRC cards from source code with WinTranslator or MacTranslator.
*Information can be exported to other development tools as the CRC cards can be exported to MacA&D, WinA&D or QuickUML to auto-generate UML class diagrams.
*It can generate a text or HTML coding specification, generate cards, attributes and responsibilities from selected words in a text file or selectively print CRC cards for a peer review. Design work is saved as an XML file.

=== ECoDE (Ectropic Collaborative Design Environment) ===

The Ectropic Collaborative Design Environment, ECoDE, is a development tool designed to capture two key components of Ectropic design: Collaborations (CRC Cards) and Scenarios. ECoDE includes a graphical user interface targeting novice software designers and attempts to present an environment that couples the flexible and modular structure of well-designed object-oriented software and perspicuity of functionally organized software.The main interface called the Ectropic Design Navigator consists of two tools namely The CRC Card Navigator and the Scenarios Navigator. The design process consists of three phases:

Analysis mode: This phase involves identifying and analyzing the program goals, identifying candidate classes to meet them, determining the responsibilities and distributing them among the candidate classes. It also involves creating scenarios for identifying the required responsibilities and building Scenarios from a sequence of CRC Card Responsibility pairs.

Design mode: This phase aims at designing a complete and implementable design. It involves reviewing each CRC card and assigning a corresponding method to each responsibility assigned to the card. In this mode the designer can create, categorize, and describe methods and match them with specific responsibilities apart from the tasks available in the analysis phase.

Program Phase: In this phase the tool checks all the CRC cards and makes sure that all the responsibilities have been assigned their corresponding methods. This allows in fixing deficiencies. It also provides the ability to convert CRC cards to actual Classes after which it asks the designer to provide attributes for the class and generates source code stubs which can then be completely implemented by the designer.

=== CRC Design Assistant ===

The CRC Design assistant is a freely available software tool that was developed to make the CRC design process easy for students. The system consists of a simple Access database and a set of classes. The database stores the design information for the classes, responsibilities, collaborations, contracts, subsystems, users, and documentation.

Some of the important features of this tool are:

*The CRC view has index cards scattered around the workspace. It uses drag-and-drop to make changes to a design. Dragging one card into another automatically makes changes to both the classes. This ensures that changes in the design are consistent.
*The CRC view also makes identifying classes with too many responsibilities easier and also helps in identifying classes that are too interconnected with the rest of the system.
*The tool provides automatic documentation for the application design. The document is in rich text format (RTF) which can be opened with Microsoft Word or WordPerfect.
*It generates comma separated variable (CSV) files that can be opened with Microsoft Visio to create CRC diagrams and object diagrams.
*Lines are drawn to represent collaborations between classes thus making it easy to visualize the extent of coupling in the system.
*Allows the designer to view the design at different levels of complexity by providing support for subsystem abstraction and grouping classes performing related tasks into a subsystem.
*It allows us to handle the growth in workspace by providing an option to print the CRC cards from the database and use the traditional approach and update the database after a work session. We could also use a projector or an electronic whiteboard for the same.

=== Visual Paradigm for UML ===

Visual Paradigm for UML is a CASE tool for UML diagrams. It supports thirteen types of diagrams.Type of diagram can be selected from Diagram navigator. The option to select CRC card diagram is found under requirements capturing tab.Selecting a new CRC card diagram opens up a new diagram toolbar. We can create cards by selecting CRC Card from diagram tool. A new CRC card appears on screen. The properties have to be edited. We can edit Card name (class name), Super classes, sub classes, its attributes, its responsibilities and its collaborators. Attributes and responsibilities may be added by right clicking on attributes or responsibilities heading and click on add attribute or responsibility. Name of attribute and description can be entered and while entering responsibility Name and its collaborator are entered.

=== Easy CRC ===

EasyCRC combines CRC cards and sequence diagrams. It is originally developed to teach Object oriented paradigm. Most of UML tools don’t include CRC cards and diagrams which give conceptual view of the system rather they focus more on implementation view of the system. EasyCRC is the only tool that focuses on CRC cards and scenarios. If any changes occur to sequence diagrams we can make changes to CRC diagrams as well.
It also provides a text editor where the description can be copy pasted and the tool picks out the noun in the description and lists them. We can select the most appropriate nouns from the list and add them to the noun list. We can also select the words that were not listed by the tool by highlighting the word and adding it to noun list.There are two ways to update the responsibilities and collaborators in CRC diagram. First one is we enter all the values manually. The other method is to draw the sequence diagrams first and from these diagrams the responsibilities and collaborators of a class would be identified and updated.

=== Interactive 3D CRC Cards (Flying Circus) ===

In general 2D diagrams, it is difficult to see the entire diagram and its collaborators. This restricts the process of understanding the diagram and coming up with new collaborators. To avoid these a CRC card diagram can be drawn in a 3D space. Flying Circus is an automated 3D tool that aids the technique of CRC card design. CRC cards can be created, modified and placed in a 3D environment. The collaborations between the classes can be shown by links between the classes. Cards can be of different sizes, can use different colors and have comments included in it. Different colors make the easily visible however small the card may be. Flying circus is built out of open source projects like OpenSceneGraph(OSG), libsigc++, Flex etc. Flying circus provides functionalities like creating CRC card, deleting a CRC card, collaborators update, change of information on CRC card, change of properties of CRC cards, 3D Manipulators to position it at a desired place in 3D space.

=== Merobase Component Finder ===

It is an online software search engine. It supports simple text based search , interface search , module lookup. The software can be searched and reused. The query is searched in various sources like SourceForge etc. Merobase allows user to define a CRC card and searches its database for matching components and displays it to user. He can reuse the cards and software associated with it.

=== Software Ideas Modeler ===

Software Ideas Modeler is a light weight tool that supports 14 types of UML diagrams. On starting the tool it shows all the 14 type of diagrams it supports and asks to choose one among them. After selecting CRC diagram, a diagram toolbox is opened. From there we can select a new CRC card or a link and few other shapes are also provided. When a new CRC card is added, the name can be changed by clicking the name box. The propertied can be edited by double clicking the crc card. This opens up a property pop up box. All the required details can be filled up. At the bottom of CRC a 2 plus symbols is green color are provided. One is to add collaborator and the other one is to add responsibility. A comment button is also provided. All CRC cards can be created and collaborating cards can be linked using a link from diagram tool box.

CSC/ECE 517 Fall 2011

2011-10-18T04:24:10Z

Sgade:

[[Link title]]
*[[CSC/ECE 517 Fall 2011/ch1 1a ms]]

*[[CSC/ECE 517 Fall 2011/ch1 1a cs]]

*[[CSC/ECE 517 Fall 2011/ch1 1a ri]]

*[[CSC/ECE 517 Fall 2011/ch1 1a lj]]

*[[CSC/ECE 517 Fall 2011/ch1 1b sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1b ds]]

*[[CSC/ECE 517 Fall 2011/ch1 1b tj]]

*[[CSC/ECE 517 Fall 2011/ch1 1c cm]]

*[[CSC/ECE 517 Fall 2011/ch1 1c sj]]

*[[CSC/ECE 517 Fall 2011/ch1 1c ka]]

*[[CSC/ECE 517 Fall 2011/ch1 1d sr]]

*[[CSC/ECE 517 Fall 2011/ch1 1e vs]]

*[[CSC/ECE 517 Fall 2011/ch1 1e aa]]

*[[CSC/ECE 517 Fall 2011/ch1 1a sc]]

*[[CSC/ECE 517 Fall 2011/ch1 1e dm]]

*[[CSC/ECE 517 Fall 2011/ch1 1e an]]

*[[CSC/ECE 517 Fall 2011/ch1 1e sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1e lm]]

*[[CSC/ECE 517 Fall 2011/ch1 1g vn]]

*[[CSC/ECE 517 Fall 2011/ch1 1f rs]]

*[[CSC/ECE 517 Fall 2011/ch1 1f sv]]

*[[CSC/ECE 517 Fall 2011/ch1 1g jn]]

*[[CSC/ECE 517 Fall 2011/ch1 1h ps]]

*[[CSC/ECE 517 Fall 2011/ch1 1e sm]]

*[[CSC/ECE 517 Fall 2011/ch1 1i zf]]

*[[CSC/ECE 517 Fall 2011/ch1 1g rn]]

*[[CSC/ECE 517 Fall 2011/ch1 1i cl]]

*[[CSC/ECE 517 Fall 2011/ch1 1d ss]]

*[[CSC/ECE 517 Fall 2011/ch1 1i lj]]

*[[CSC/ECE 517 Fall 2011/ch1 1h hs]]

*[[CSC/ECE 517 Fall 2011/ch1 1d gs]]

*[[CSC/ECE 517 Fall 2011/ch1 2b ns]]

*[[CSC/ECE 517 Fall 2011/ch1 2b jp]]

*[[CSC/ECE 517 Fall 2011/ch1 2a av]]

*[[CSC/ECE 517 Fall 2011/ch2 2f jm]]

*[[CSC/ECE 517 Fall 2011/ch2 2e ad]]

*[[CSC/ECE 517 Fall 2011/ch2 2e kt]]

*[[CSC/ECE 517 Fall 2011/ch2 2e gp]]

*[[CSC/ECE 517 Fall 2011/ch1 2b qu]]

*[[CSC/ECE 517 Fall 2011/ch2 2c bs]]

*[[CSC/ECE 517 Fall 2011/ch1 2c rs]]

*[[CSC/ECE 517 Fall 2011/ch1 2a ca]]

*[[CSC/ECE 517 Fall 2011/ch1 2b rv]]

*[[CSC/ECE 517 Fall 2011/ch2 2c ds]]

*[[CSC/ECE 517 Fall 2011/ch2 2b sa]]

*[[CSC/ECE 517 Fall 2011/ch2 2f vh]]

*[[CSC/ECE 517 Fall 2011/ch2 2e ps]]

*[[CSC/ECE 517 Fall 2011/ch3 3a oe]]

*[[CSC/ECE 517 Fall 2011/ch3 3h rr]]

*[[CSC/ECE 517 Fall 2011/ch3 3h ss]]

*[[CSC/ECE 517 Fall 2011/ch3 4b js]]

*[[CSC/ECE 517 Fall 2011/ch3 4b ms]]

*[[CSC/ECE 517 Fall 2011/ch4 4i aa]]

*[[CSC/ECE 517 Fall 2011/ch4 4i sd]]

*[[CSC/ECE 517 Fall 2011/ch4 4d mt]]

*[[CSC/ECE 517 Fall 2011/ch4 4d ls]]

*[[CSC/ECE 517 Fall 2011/ch4 4d ch]]

*[[CSC/ECE 517 Fall 2011/ch4 4c ap]]

*[[CSC/ECE 517 Fall 2011/ch4 4h sv]]

*[[CSC/ECE 517 Fall 2011/ch4 4e cl]]

*[[CSC/ECE 517 Fall 2011/ch4 4a ga]]

*[[CSC/ECE 517 Fall 2011/ch4 4f sl]]

*[[CSC/ECE 517 Fall 2011/ch4 4i js]]

*[[trial]]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:57:57Z

Sgade: /* Further Reading */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development time lines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first Object oriented Programming language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current Object oriented Programming languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.<ref>[http://en.wikipedia.org/wiki/Structured_programming Structured Programming]</ref>

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) is essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class). A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.<ref>[http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false Beginning Programming All-In-One Desk Reference For Dummies]</ref>

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, subroutines are written for and can be used only to perform a specific task. They cannot be reused when the task at hand is different or an extension of the functionality for which that particular function was written.

As an example of a Base class we can consider the following Bicycle class:

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are some other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The Object-oriented Programming approach reverses the emphasis of data and functions used in structured programming. In Object-oriented Programming, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."<ref>[http://bulletin.sigchi.org/1997/october/papers/ross/ Structured Programmers Learning Object-Oriented Programming]</ref>

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

The following is an example of polymorphism exhibited in the constructors of a class
public class Website {

String name;
String url;
String description;

public Website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public Website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

The differences between Structured and Object-oriented Programming are briefed below:<ref>[http://www.buyya.com/java/Chapter1.pdf Software Development and Object-Oriented Programming Paradigms]</ref>

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

='''References'''=
<references>
</references>

== Further Reading ==

1. Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

2. Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

3. [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

4. http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

5. Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

6. Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:57:39Z

Sgade: /* What is a better choice */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development time lines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first Object oriented Programming language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current Object oriented Programming languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.<ref>[http://en.wikipedia.org/wiki/Structured_programming Structured Programming]</ref>

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) is essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class). A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.<ref>[http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false Beginning Programming All-In-One Desk Reference For Dummies]</ref>

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, subroutines are written for and can be used only to perform a specific task. They cannot be reused when the task at hand is different or an extension of the functionality for which that particular function was written.

As an example of a Base class we can consider the following Bicycle class:

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are some other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The Object-oriented Programming approach reverses the emphasis of data and functions used in structured programming. In Object-oriented Programming, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."<ref>[http://bulletin.sigchi.org/1997/october/papers/ross/ Structured Programmers Learning Object-Oriented Programming]</ref>

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

The following is an example of polymorphism exhibited in the constructors of a class
public class Website {

String name;
String url;
String description;

public Website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public Website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

The differences between Structured and Object-oriented Programming are briefed below:<ref>[http://www.buyya.com/java/Chapter1.pdf Software Development and Object-Oriented Programming Paradigms]</ref>

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

='''References'''=
<references>
</references>

== Further Reading ==

1. Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

2. Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

3. [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

4. http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

5. Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:57:09Z

Sgade: /* What is a better choice */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development time lines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first Object oriented Programming language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current Object oriented Programming languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.<ref>[http://en.wikipedia.org/wiki/Structured_programming Structured Programming]</ref>

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) is essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class). A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.<ref>[http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false Beginning Programming All-In-One Desk Reference For Dummies]</ref>

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, subroutines are written for and can be used only to perform a specific task. They cannot be reused when the task at hand is different or an extension of the functionality for which that particular function was written.

As an example of a Base class we can consider the following Bicycle class:

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are some other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The Object-oriented Programming approach reverses the emphasis of data and functions used in structured programming. In Object-oriented Programming, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."<ref>[http://bulletin.sigchi.org/1997/october/papers/ross/ Structured Programmers Learning Object-Oriented Programming]</ref>

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

The following is an example of polymorphism exhibited in the constructors of a class
public class Website {

String name;
String url;
String description;

public Website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public Website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

The differences between Structured and Object-oriented Programming are briefed below:<ref>[http://www.buyya.com/java/Chapter1.pdf Software Development
and Object-Oriented
Programming Paradigms]</ref>

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

='''References'''=
<references>
</references>

== Further Reading ==

1. Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

2. Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

3. [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

4. http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

5. Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:56:27Z

Sgade: /* Focus */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development time lines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first Object oriented Programming language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current Object oriented Programming languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.<ref>[http://en.wikipedia.org/wiki/Structured_programming Structured Programming]</ref>

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) is essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class). A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.<ref>[http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false Beginning Programming All-In-One Desk Reference For Dummies]</ref>

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, subroutines are written for and can be used only to perform a specific task. They cannot be reused when the task at hand is different or an extension of the functionality for which that particular function was written.

As an example of a Base class we can consider the following Bicycle class:

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are some other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The Object-oriented Programming approach reverses the emphasis of data and functions used in structured programming. In Object-oriented Programming, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."<ref>[http://bulletin.sigchi.org/1997/october/papers/ross/ Structured Programmers Learning Object-Oriented Programming]</ref>

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

The following is an example of polymorphism exhibited in the constructors of a class
public class Website {

String name;
String url;
String description;

public Website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public Website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

The differences between Structured and Object-oriented Programming are briefed below:<ref>[http://www.buyya.com/java/Chapter1.pdf]</ref>

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

='''References'''=
<references>
</references>

== Further Reading ==

1. Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

2. Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

3. [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

4. http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

5. Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:55:54Z

Sgade: /* Abstraction */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development time lines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first Object oriented Programming language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current Object oriented Programming languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.<ref>[http://en.wikipedia.org/wiki/Structured_programming Structured Programming]</ref>

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) is essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class). A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.<ref>[http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false Beginning Programming All-In-One Desk Reference For Dummies]</ref>

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, subroutines are written for and can be used only to perform a specific task. They cannot be reused when the task at hand is different or an extension of the functionality for which that particular function was written.

As an example of a Base class we can consider the following Bicycle class:

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are some other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The Object-oriented Programming approach reverses the emphasis of data and functions used in structured programming. In Object-oriented Programming, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."<ref>[http://bulletin.sigchi.org/1997/october/papers/ross/]</ref>

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

The following is an example of polymorphism exhibited in the constructors of a class
public class Website {

String name;
String url;
String description;

public Website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public Website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

The differences between Structured and Object-oriented Programming are briefed below:<ref>[http://www.buyya.com/java/Chapter1.pdf]</ref>

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

='''References'''=
<references>
</references>

== Further Reading ==

1. Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

2. Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

3. [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

4. http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

5. Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:55:08Z

Sgade: /* Evolution from Structured to Object oriented Programming */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development time lines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first Object oriented Programming language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current Object oriented Programming languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.<ref>[http://en.wikipedia.org/wiki/Structured_programming Structured Programming]</ref>

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) is essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class). A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.<ref>[http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false]</ref>

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, subroutines are written for and can be used only to perform a specific task. They cannot be reused when the task at hand is different or an extension of the functionality for which that particular function was written.

As an example of a Base class we can consider the following Bicycle class:

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are some other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The Object-oriented Programming approach reverses the emphasis of data and functions used in structured programming. In Object-oriented Programming, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."<ref>[http://bulletin.sigchi.org/1997/october/papers/ross/]</ref>

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

The following is an example of polymorphism exhibited in the constructors of a class
public class Website {

String name;
String url;
String description;

public Website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public Website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

The differences between Structured and Object-oriented Programming are briefed below:<ref>[http://www.buyya.com/java/Chapter1.pdf]</ref>

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

='''References'''=
<references>
</references>

== Further Reading ==

1. Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

2. Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

3. [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

4. http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

5. Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:53:57Z

Sgade: /* Evolution from Structured to Object oriented Programming */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development time lines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first Object oriented Programming language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current Object oriented Programming languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.<ref>[http://en.wikipedia.org/wiki/Structured_programming]</ref>

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) is essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class). A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.<ref>[http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false]</ref>

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, subroutines are written for and can be used only to perform a specific task. They cannot be reused when the task at hand is different or an extension of the functionality for which that particular function was written.

As an example of a Base class we can consider the following Bicycle class:

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are some other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The Object-oriented Programming approach reverses the emphasis of data and functions used in structured programming. In Object-oriented Programming, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."<ref>[http://bulletin.sigchi.org/1997/october/papers/ross/]</ref>

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

The following is an example of polymorphism exhibited in the constructors of a class
public class Website {

String name;
String url;
String description;

public Website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public Website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

The differences between Structured and Object-oriented Programming are briefed below:<ref>[http://www.buyya.com/java/Chapter1.pdf]</ref>

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

='''References'''=
<references>
</references>

== Further Reading ==

1. Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

2. Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

3. [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

4. http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

5. Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:53:32Z

Sgade: /* Abstraction */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development time lines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first Object oriented Programming language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current Object oriented Programming languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.[http://en.wikipedia.org/wiki/Structured_programming]

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) is essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class). A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.<ref>[http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false]</ref>

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, subroutines are written for and can be used only to perform a specific task. They cannot be reused when the task at hand is different or an extension of the functionality for which that particular function was written.

As an example of a Base class we can consider the following Bicycle class:

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are some other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The Object-oriented Programming approach reverses the emphasis of data and functions used in structured programming. In Object-oriented Programming, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."<ref>[http://bulletin.sigchi.org/1997/october/papers/ross/]</ref>

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

The following is an example of polymorphism exhibited in the constructors of a class
public class Website {

String name;
String url;
String description;

public Website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public Website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

The differences between Structured and Object-oriented Programming are briefed below:<ref>[http://www.buyya.com/java/Chapter1.pdf]</ref>

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

='''References'''=
<references>
</references>

== Further Reading ==

1. Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

2. Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

3. [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

4. http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

5. Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:53:04Z

Sgade: /* Focus */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development time lines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first Object oriented Programming language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current Object oriented Programming languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.[http://en.wikipedia.org/wiki/Structured_programming]

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) is essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class). A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.[http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false]

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, subroutines are written for and can be used only to perform a specific task. They cannot be reused when the task at hand is different or an extension of the functionality for which that particular function was written.

As an example of a Base class we can consider the following Bicycle class:

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are some other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The Object-oriented Programming approach reverses the emphasis of data and functions used in structured programming. In Object-oriented Programming, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."<ref>[http://bulletin.sigchi.org/1997/october/papers/ross/]</ref>

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

The following is an example of polymorphism exhibited in the constructors of a class
public class Website {

String name;
String url;
String description;

public Website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public Website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

The differences between Structured and Object-oriented Programming are briefed below:<ref>[http://www.buyya.com/java/Chapter1.pdf]</ref>

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

='''References'''=
<references>
</references>

== Further Reading ==

1. Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

2. Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

3. [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

4. http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

5. Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:52:40Z

Sgade: /* What is a better choice */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development time lines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first Object oriented Programming language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current Object oriented Programming languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.[http://en.wikipedia.org/wiki/Structured_programming]

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) is essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class). A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.[http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false]

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, subroutines are written for and can be used only to perform a specific task. They cannot be reused when the task at hand is different or an extension of the functionality for which that particular function was written.

As an example of a Base class we can consider the following Bicycle class:

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are some other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The Object-oriented Programming approach reverses the emphasis of data and functions used in structured programming. In Object-oriented Programming, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."[http://bulletin.sigchi.org/1997/october/papers/ross/]

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

The following is an example of polymorphism exhibited in the constructors of a class
public class Website {

String name;
String url;
String description;

public Website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public Website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

The differences between Structured and Object-oriented Programming are briefed below:<ref>[http://www.buyya.com/java/Chapter1.pdf]</ref>

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

='''References'''=
<references>
</references>

== Further Reading ==

1. Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

2. Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

3. [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

4. http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

5. Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:51:19Z

Sgade: /* References */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development time lines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first Object oriented Programming language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current Object oriented Programming languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.[http://en.wikipedia.org/wiki/Structured_programming]

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) is essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class). A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.[http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false]

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, subroutines are written for and can be used only to perform a specific task. They cannot be reused when the task at hand is different or an extension of the functionality for which that particular function was written.

As an example of a Base class we can consider the following Bicycle class:

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are some other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The Object-oriented Programming approach reverses the emphasis of data and functions used in structured programming. In Object-oriented Programming, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."[http://bulletin.sigchi.org/1997/october/papers/ross/]

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

The following is an example of polymorphism exhibited in the constructors of a class
public class Website {

String name;
String url;
String description;

public Website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public Website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

The differences between Structured and Object-oriented Programming are briefed below:[http://www.buyya.com/java/Chapter1.pdf]

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

='''References'''=
<references>
</references>

== Further Reading ==

1. Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

2. Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

3. [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

4. http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

5. Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:50:45Z

Sgade: /* Evolution from Structured to Object oriented Programming */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development time lines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first Object oriented Programming language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current Object oriented Programming languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.[http://en.wikipedia.org/wiki/Structured_programming]

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) is essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class). A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.[http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false]

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, subroutines are written for and can be used only to perform a specific task. They cannot be reused when the task at hand is different or an extension of the functionality for which that particular function was written.

As an example of a Base class we can consider the following Bicycle class:

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are some other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The Object-oriented Programming approach reverses the emphasis of data and functions used in structured programming. In Object-oriented Programming, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."[http://bulletin.sigchi.org/1997/october/papers/ross/]

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

The following is an example of polymorphism exhibited in the constructors of a class
public class Website {

String name;
String url;
String description;

public Website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public Website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

The differences between Structured and Object-oriented Programming are briefed below:[http://www.buyya.com/java/Chapter1.pdf]

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

== References ==

[1] [http://bulletin.sigchi.org/1997/october/papers/ross/ Structured Programmers Learning Object-Oriented Programming]

[2] [http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false Beginning Programming All-In-One Desk Reference For Dummies]

[3] [http://www.buyya.com/java/Chapter1.pdf Software Development and Object-Oriented Programming Paradigms]

[4] [http://en.wikipedia.org/wiki/Structured_programming Structured Programming]

== Further Reading ==

1. Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

2. Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

3. [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

4. http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

5. Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:50:10Z

Sgade: /* What is a better choice */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development time lines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first Object oriented Programming language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current Object oriented Programming languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) is essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class). A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.[http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false]

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, subroutines are written for and can be used only to perform a specific task. They cannot be reused when the task at hand is different or an extension of the functionality for which that particular function was written.

As an example of a Base class we can consider the following Bicycle class:

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are some other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The Object-oriented Programming approach reverses the emphasis of data and functions used in structured programming. In Object-oriented Programming, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."[http://bulletin.sigchi.org/1997/october/papers/ross/]

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

The following is an example of polymorphism exhibited in the constructors of a class
public class Website {

String name;
String url;
String description;

public Website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public Website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

The differences between Structured and Object-oriented Programming are briefed below:[http://www.buyya.com/java/Chapter1.pdf]

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

== References ==

[1] [http://bulletin.sigchi.org/1997/october/papers/ross/ Structured Programmers Learning Object-Oriented Programming]

[2] [http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false Beginning Programming All-In-One Desk Reference For Dummies]

[3] [http://www.buyya.com/java/Chapter1.pdf Software Development and Object-Oriented Programming Paradigms]

[4] [http://en.wikipedia.org/wiki/Structured_programming Structured Programming]

== Further Reading ==

1. Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

2. Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

3. [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

4. http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

5. Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:49:56Z

Sgade: /* What is a better choice */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development time lines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first Object oriented Programming language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current Object oriented Programming languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) is essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class). A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.[http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false]

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, subroutines are written for and can be used only to perform a specific task. They cannot be reused when the task at hand is different or an extension of the functionality for which that particular function was written.

As an example of a Base class we can consider the following Bicycle class:

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are some other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The Object-oriented Programming approach reverses the emphasis of data and functions used in structured programming. In Object-oriented Programming, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."[http://bulletin.sigchi.org/1997/october/papers/ross/]

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

The following is an example of polymorphism exhibited in the constructors of a class
public class Website {

String name;
String url;
String description;

public Website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public Website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

The differences between Structured and Object-oriented Programming are briefed below:[http://www.buyya.com/java/Chapter1.pdf Software Development and Object-Oriented Programming Paradigms]

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

== References ==

[1] [http://bulletin.sigchi.org/1997/october/papers/ross/ Structured Programmers Learning Object-Oriented Programming]

[2] [http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false Beginning Programming All-In-One Desk Reference For Dummies]

[3] [http://www.buyya.com/java/Chapter1.pdf Software Development and Object-Oriented Programming Paradigms]

[4] [http://en.wikipedia.org/wiki/Structured_programming Structured Programming]

== Further Reading ==

1. Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

2. Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

3. [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

4. http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

5. Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:49:26Z

Sgade: /* Focus */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development time lines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first Object oriented Programming language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current Object oriented Programming languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) is essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class). A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.[http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false]

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, subroutines are written for and can be used only to perform a specific task. They cannot be reused when the task at hand is different or an extension of the functionality for which that particular function was written.

As an example of a Base class we can consider the following Bicycle class:

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are some other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The Object-oriented Programming approach reverses the emphasis of data and functions used in structured programming. In Object-oriented Programming, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."[http://bulletin.sigchi.org/1997/october/papers/ross/]

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

The following is an example of polymorphism exhibited in the constructors of a class
public class Website {

String name;
String url;
String description;

public Website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public Website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

The differences between Structured and Object-oriented Programming are briefed below:

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

== References ==

[1] [http://bulletin.sigchi.org/1997/october/papers/ross/ Structured Programmers Learning Object-Oriented Programming]

[2] [http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false Beginning Programming All-In-One Desk Reference For Dummies]

[3] [http://www.buyya.com/java/Chapter1.pdf Software Development and Object-Oriented Programming Paradigms]

[4] [http://en.wikipedia.org/wiki/Structured_programming Structured Programming]

== Further Reading ==

1. Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

2. Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

3. [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

4. http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

5. Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:49:13Z

Sgade: /* Abstraction */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development time lines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first Object oriented Programming language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current Object oriented Programming languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) is essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class). A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.[http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false]

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, subroutines are written for and can be used only to perform a specific task. They cannot be reused when the task at hand is different or an extension of the functionality for which that particular function was written.

As an example of a Base class we can consider the following Bicycle class:

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are some other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The Object-oriented Programming approach reverses the emphasis of data and functions used in structured programming. In Object-oriented Programming, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

The following is an example of polymorphism exhibited in the constructors of a class
public class Website {

String name;
String url;
String description;

public Website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public Website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

The differences between Structured and Object-oriented Programming are briefed below:

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

== References ==

[1] [http://bulletin.sigchi.org/1997/october/papers/ross/ Structured Programmers Learning Object-Oriented Programming]

[2] [http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false Beginning Programming All-In-One Desk Reference For Dummies]

[3] [http://www.buyya.com/java/Chapter1.pdf Software Development and Object-Oriented Programming Paradigms]

[4] [http://en.wikipedia.org/wiki/Structured_programming Structured Programming]

== Further Reading ==

1. Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

2. Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

3. [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

4. http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

5. Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:48:11Z

Sgade: /* Focus */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development time lines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first Object oriented Programming language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current Object oriented Programming languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) is essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class). A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.[http://bulletin.sigchi.org/1997/october/papers/ross/]

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, subroutines are written for and can be used only to perform a specific task. They cannot be reused when the task at hand is different or an extension of the functionality for which that particular function was written.

As an example of a Base class we can consider the following Bicycle class:

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are some other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The Object-oriented Programming approach reverses the emphasis of data and functions used in structured programming. In Object-oriented Programming, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

The following is an example of polymorphism exhibited in the constructors of a class
public class Website {

String name;
String url;
String description;

public Website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public Website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

The differences between Structured and Object-oriented Programming are briefed below:

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

== References ==

[1] [http://bulletin.sigchi.org/1997/october/papers/ross/ Structured Programmers Learning Object-Oriented Programming]

[2] [http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false Beginning Programming All-In-One Desk Reference For Dummies]

[3] [http://www.buyya.com/java/Chapter1.pdf Software Development and Object-Oriented Programming Paradigms]

[4] [http://en.wikipedia.org/wiki/Structured_programming Structured Programming]

== Further Reading ==

1. Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

2. Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

3. [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

4. http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

5. Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:47:17Z

Sgade: /* Focus */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development time lines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first Object oriented Programming language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current Object oriented Programming languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) is essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class). A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.[http://bulletin.sigchi.org/1997/october/papers/ross/]

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, subroutines are written for and can be used only to perform a specific task. They cannot be reused when the task at hand is different or an extension of the functionality for which that particular function was written.

As an example of a Base class we can consider the following Bicycle class:

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are some other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The Object-oriented Programming approach reverses the emphasis of data and functions used in structured programming. In Object-oriented Programming, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."[http://bulletin.sigchi.org/1997/october/papers/ross/]

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

The following is an example of polymorphism exhibited in the constructors of a class
public class Website {

String name;
String url;
String description;

public Website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public Website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

The differences between Structured and Object-oriented Programming are briefed below:

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

== References ==

[1] [http://bulletin.sigchi.org/1997/october/papers/ross/ Structured Programmers Learning Object-Oriented Programming]

[2] [http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false Beginning Programming All-In-One Desk Reference For Dummies]

[3] [http://www.buyya.com/java/Chapter1.pdf Software Development and Object-Oriented Programming Paradigms]

[4] [http://en.wikipedia.org/wiki/Structured_programming Structured Programming]

== Further Reading ==

1. Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

2. Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

3. [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

4. http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

5. Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:46:35Z

Sgade: /* Abstraction */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development time lines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first Object oriented Programming language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current Object oriented Programming languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) is essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class). A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.[http://bulletin.sigchi.org/1997/october/papers/ross/]

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, subroutines are written for and can be used only to perform a specific task. They cannot be reused when the task at hand is different or an extension of the functionality for which that particular function was written.

As an example of a Base class we can consider the following Bicycle class:

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are some other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The Object-oriented Programming approach reverses the emphasis of data and functions used in structured programming. In Object-oriented Programming, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

The following is an example of polymorphism exhibited in the constructors of a class
public class Website {

String name;
String url;
String description;

public Website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public Website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

The differences between Structured and Object-oriented Programming are briefed below:

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

== References ==

[1] [http://bulletin.sigchi.org/1997/october/papers/ross/ Structured Programmers Learning Object-Oriented Programming]

[2] [http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false Beginning Programming All-In-One Desk Reference For Dummies]

[3] [http://www.buyya.com/java/Chapter1.pdf Software Development and Object-Oriented Programming Paradigms]

[4] [http://en.wikipedia.org/wiki/Structured_programming Structured Programming]

== Further Reading ==

1. Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

2. Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

3. [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

4. http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

5. Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:45:20Z

Sgade: /* References */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development time lines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first Object oriented Programming language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current Object oriented Programming languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) is essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class). A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, subroutines are written for and can be used only to perform a specific task. They cannot be reused when the task at hand is different or an extension of the functionality for which that particular function was written.

As an example of a Base class we can consider the following Bicycle class:

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are some other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The Object-oriented Programming approach reverses the emphasis of data and functions used in structured programming. In Object-oriented Programming, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

The following is an example of polymorphism exhibited in the constructors of a class
public class Website {

String name;
String url;
String description;

public Website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public Website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

The differences between Structured and Object-oriented Programming are briefed below:

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

== References ==

[1] [http://bulletin.sigchi.org/1997/october/papers/ross/ Structured Programmers Learning Object-Oriented Programming]

[2] [http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false Beginning Programming All-In-One Desk Reference For Dummies]

[3] [http://www.buyya.com/java/Chapter1.pdf Software Development and Object-Oriented Programming Paradigms]

[4] [http://en.wikipedia.org/wiki/Structured_programming Structured Programming]

== Further Reading ==

1. Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

2. Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

3. [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

4. http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

5. Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:34:50Z

Sgade: /* What is a better choice */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development time lines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first Object oriented Programming language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current Object oriented Programming languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) is essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class). A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, subroutines are written for and can be used only to perform a specific task. They cannot be reused when the task at hand is different or an extension of the functionality for which that particular function was written.

As an example of a Base class we can consider the following Bicycle class:

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are some other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The Object-oriented Programming approach reverses the emphasis of data and functions used in structured programming. In Object-oriented Programming, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

The following is an example of polymorphism exhibited in the constructors of a class
public class Website {

String name;
String url;
String description;

public Website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public Website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

The differences between Structured and Object-oriented Programming are briefed below:

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

== References ==

[1] [http://bulletin.sigchi.org/1997/october/papers/ross/ Structured Programmers Learning Object-Oriented Programming]

[2] [http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false Beginning Programming All-In-One Desk Reference For Dummies]

[3] [http://www.buyya.com/java/Chapter1.pdf Software Development and Object-Oriented Programming Paradigms]

[4] [http://en.wikipedia.org/wiki/Structured_programming Structured Programming]

[5] Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

[6] Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

[7] [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

[8] http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

[9] Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:30:25Z

Sgade: /* Polymorphism */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development time lines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first Object oriented Programming language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current Object oriented Programming languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) is essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class). A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, subroutines are written for and can be used only to perform a specific task. They cannot be reused when the task at hand is different or an extension of the functionality for which that particular function was written.

As an example of a Base class we can consider the following Bicycle class:

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are some other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The Object-oriented Programming approach reverses the emphasis of data and functions used in structured programming. In Object-oriented Programming, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

The following is an example of polymorphism exhibited in the constructors of a class
public class Website {

String name;
String url;
String description;

public Website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public Website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

== References ==

[1] [http://bulletin.sigchi.org/1997/october/papers/ross/ Structured Programmers Learning Object-Oriented Programming]

[2] [http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false Beginning Programming All-In-One Desk Reference For Dummies]

[3] [http://www.buyya.com/java/Chapter1.pdf Software Development and Object-Oriented Programming Paradigms]

[4] [http://en.wikipedia.org/wiki/Structured_programming Structured Programming]

[5] Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

[6] Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

[7] [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

[8] http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

[9] Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:27:09Z

Sgade: /* Focus */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development time lines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first Object oriented Programming language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current Object oriented Programming languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) is essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class). A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, subroutines are written for and can be used only to perform a specific task. They cannot be reused when the task at hand is different or an extension of the functionality for which that particular function was written.

As an example of a Base class we can consider the following Bicycle class:

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are some other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The Object-oriented Programming approach reverses the emphasis of data and functions used in structured programming. In Object-oriented Programming, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

public class website {

String name;
String url;
String description;

public website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

== References ==

[1] [http://bulletin.sigchi.org/1997/october/papers/ross/ Structured Programmers Learning Object-Oriented Programming]

[2] [http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false Beginning Programming All-In-One Desk Reference For Dummies]

[3] [http://www.buyya.com/java/Chapter1.pdf Software Development and Object-Oriented Programming Paradigms]

[4] [http://en.wikipedia.org/wiki/Structured_programming Structured Programming]

[5] Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

[6] Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

[7] [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

[8] http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

[9] Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:24:20Z

Sgade: /* Reusability */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development time lines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first Object oriented Programming language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current Object oriented Programming languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) is essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class). A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, subroutines are written for and can be used only to perform a specific task. They cannot be reused when the task at hand is different or an extension of the functionality for which that particular function was written.

As an example of a Base class we can consider the following Bicycle class:

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are some other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The OOP approach reverses the emphasis of data and functions used in structured programming. In OOP, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert (1990) contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

public class website {

String name;
String url;
String description;

public website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

== References ==

[1] [http://bulletin.sigchi.org/1997/october/papers/ross/ Structured Programmers Learning Object-Oriented Programming]

[2] [http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false Beginning Programming All-In-One Desk Reference For Dummies]

[3] [http://www.buyya.com/java/Chapter1.pdf Software Development and Object-Oriented Programming Paradigms]

[4] [http://en.wikipedia.org/wiki/Structured_programming Structured Programming]

[5] Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

[6] Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

[7] [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

[8] http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

[9] Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:17:09Z

Sgade: /* Abstraction */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development time lines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first Object oriented Programming language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current Object oriented Programming languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) is essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class). A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, the only possible way in which reusability can be implemented is the same subroutine can be called multiple times.

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The OOP approach reverses the emphasis of data and functions used in structured programming. In OOP, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert (1990) contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

public class website {

String name;
String url;
String description;

public website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

== References ==

[1] [http://bulletin.sigchi.org/1997/october/papers/ross/ Structured Programmers Learning Object-Oriented Programming]

[2] [http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false Beginning Programming All-In-One Desk Reference For Dummies]

[3] [http://www.buyya.com/java/Chapter1.pdf Software Development and Object-Oriented Programming Paradigms]

[4] [http://en.wikipedia.org/wiki/Structured_programming Structured Programming]

[5] Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

[6] Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

[7] [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

[8] http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

[9] Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:13:26Z

Sgade: /* Evolution from Structured to Object oriented Programming */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development time lines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first Object oriented Programming language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current Object oriented Programming languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) are essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class. A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson (1992) put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, the only possible way in which reusability can be implemented is the same subroutine can be called multiple times.

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The OOP approach reverses the emphasis of data and functions used in structured programming. In OOP, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert (1990) contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

public class website {

String name;
String url;
String description;

public website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

== References ==

[1] [http://bulletin.sigchi.org/1997/october/papers/ross/ Structured Programmers Learning Object-Oriented Programming]

[2] [http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false Beginning Programming All-In-One Desk Reference For Dummies]

[3] [http://www.buyya.com/java/Chapter1.pdf Software Development and Object-Oriented Programming Paradigms]

[4] [http://en.wikipedia.org/wiki/Structured_programming Structured Programming]

[5] Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

[6] Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

[7] [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

[8] http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

[9] Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:08:46Z

Sgade: /* Evolution from Structured to Object oriented Programming */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development timelines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first OOP language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current OOP languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) are essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class. A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson (1992) put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, the only possible way in which reusability can be implemented is the same subroutine can be called multiple times.

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The OOP approach reverses the emphasis of data and functions used in structured programming. In OOP, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert (1990) contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

public class website {

String name;
String url;
String description;

public website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

== References ==

[1] [http://bulletin.sigchi.org/1997/october/papers/ross/ Structured Programmers Learning Object-Oriented Programming]

[2] [http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false Beginning Programming All-In-One Desk Reference For Dummies]

[3] [http://www.buyya.com/java/Chapter1.pdf Software Development and Object-Oriented Programming Paradigms]

[4] [http://en.wikipedia.org/wiki/Structured_programming Structured Programming]

[5] Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

[6] Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

[7] [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

[8] http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

[9] Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-26T00:00:14Z

Sgade: /* Analysis and Design Differences */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Regardless of the language used prior to OOP, programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development timelines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first OOP language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current OOP languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) are essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class. A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson (1992) put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, the only possible way in which reusability can be implemented is the same subroutine can be called multiple times.

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The OOP approach reverses the emphasis of data and functions used in structured programming. In OOP, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert (1990) contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

public class website {

String name;
String url;
String description;

public website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.

In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

== References ==

[1] [http://bulletin.sigchi.org/1997/october/papers/ross/ Structured Programmers Learning Object-Oriented Programming]

[2] [http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false Beginning Programming All-In-One Desk Reference For Dummies]

[3] [http://www.buyya.com/java/Chapter1.pdf Software Development and Object-Oriented Programming Paradigms]

[4] [http://en.wikipedia.org/wiki/Structured_programming Structured Programming]

[5] Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

[6] Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

[7] [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

[8] http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

[9] Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-25T23:59:30Z

Sgade:

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Regardless of the language used prior to OOP, programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development timelines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first OOP language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current OOP languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) are essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class. A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson (1992) put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, the only possible way in which reusability can be implemented is the same subroutine can be called multiple times.

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The OOP approach reverses the emphasis of data and functions used in structured programming. In OOP, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert (1990) contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

public class website {

String name;
String url;
String description;

public website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public website() {
name = "";
url = "";
description = "";
}

}

== Analysis and Design Differences ==

In structured programming, while analysis starts with a consideration of real-world problems, the real-world focus is lost as requirements are transformed into a series of data flow diagrams which is the intermediate step before the design stage. When program design takes place, the process has distanced itself from the real world. The design stage culminates in the creation of structure charts and detailed logic diagrams. By the time the programming team goes to work, they are no longer focused on the real-world objects being emulated.
In contrast, using object-oriented analysis, design, and programming techniques, the focus remains on the real-world objects throughout the development cycle. There is an overlap between each of the three development steps. The analyst and the programmer are both interested in development of usable (and reusable) objects. These programming objects (referred to as class declarations), once tested and made available to other programmers, do not have to be retested and redesigned every time changes are made to the data layout.

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

== References ==

[1] [http://bulletin.sigchi.org/1997/october/papers/ross/ Structured Programmers Learning Object-Oriented Programming]

[2] [http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false Beginning Programming All-In-One Desk Reference For Dummies]

[3] [http://www.buyya.com/java/Chapter1.pdf Software Development and Object-Oriented Programming Paradigms]

[4] [http://en.wikipedia.org/wiki/Structured_programming Structured Programming]

[5] Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

[6] Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

[7] [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

[8] http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

[9] Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-25T23:58:27Z

Sgade: /* References */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Regardless of the language used prior to OOP, programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development timelines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first OOP language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current OOP languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

Structured programming is suitable for small programs but for large programs, structured programming can produce cumbersome code with large amounts of data. With structured programming in large programs, for a small change, multiple subprograms will have to be changed. On the other hand, object-oriented approach is more flexible, by separating a program into a network of subsystems, with each controlling their own data, algorithms, or devices across the entire program.

The Object-Oriented approach encourages the programmer to place data where it is not directly accessible by the rest of the program. The data is accessed by calling specially written functions, commonly called methods. The programming construct that combines data with a set of methods for accessing and managing those data is called an object.

An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept. An object-oriented program may thus be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. Object-Oriented programming can lessen the gap between the programmer models and the application domain being modeled.

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) are essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class. A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson (1992) put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, the only possible way in which reusability can be implemented is the same subroutine can be called multiple times.

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The OOP approach reverses the emphasis of data and functions used in structured programming. In OOP, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert (1990) contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

public class website {

String name;
String url;
String description;

public website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public website() {
name = "";
url = "";
description = "";
}

}

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

== References ==

[1] [http://bulletin.sigchi.org/1997/october/papers/ross/ Structured Programmers Learning Object-Oriented Programming]

[2] [http://books.google.com/books?id=A71tgIY4BoMC&pg=PT59&lpg=PT59&dq=Reusability+in+structured+and+Object+Oriented+Programming&source=bl&ots=YPROMVi6qs&sig=6OG-I4TIbuUN2UUgtD47Vu7SS-o&hl=en&ei=T4J_TuvJAYW-tgfckb#v=onepage&q&f=false Beginning Programming All-In-One Desk Reference For Dummies]

[3] [http://www.buyya.com/java/Chapter1.pdf Software Development and Object-Oriented Programming Paradigms]

[4] [http://en.wikipedia.org/wiki/Structured_programming Structured Programming]

[5] Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

[6] Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

[7] [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

[8] http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573

[9] Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[10] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

CSC/ECE 517 Fall 2011/ch1 1e sm

2011-09-25T23:33:25Z

Sgade: /* References */

This article briefs about how [http://en.wikipedia.org/wiki/Object-oriented_programming Object-oriented Programming] came into being after [http://en.wikipedia.org/wiki/Structured_programming Structured Programming] prevailed for years and it compares and contrasts the various aspects of these two programming approaches. It sheds some light on the popular belief that Object-oriented technology will alleviate some of the problems associated with structured approaches.

== Evolution from Structured to Object oriented Programming ==

Regardless of the language used prior to OOP, programmers since the 1970s have embraced a style called structured programming. As with earlier "spaghetti code," computer programmers still used such concepts as variables, assignments to variables, expression construction, and function evaluation. Typically, those programmers spent long hours designing, coding, and debugging programs. Structured techniques, such as the use of subroutines rather than GOTOs, resulted in improved development timelines and increased supportability. Although improved over prior coding techniques, structured programmers found that they usually could not reuse routines already coded for earlier programs. In 1967 the first OOP language, SIMULA-67, was introduced which had several unique ways of coding subroutines with improved potential for reuse. Current OOP languages such as Java (derived from C++) and Smalltalk share commonalities with traditional structured programming languages such as C and COBOL while adding in the ideas first developed in the 60s. Despite the many commonalities, object-oriented programming is significantly different from structured programming.

== Comparison ==

=== [http://en.wikipedia.org/wiki/Abstraction_(computer_science) Abstraction] ===

In structured programming, data and functions (or procedures) are separate. The data (e.g., employees, orders, or sales records) are essentially passed to functions (e.g., print, display, add, change, and delete routines) that act on the data as required. Thus the functions can work on data from different parts of the program. If we do not know what data a function might manipulate and when, any changes we make to that function could affect a program in unpredictable ways. This makes the task of modifying and fixing the code harder.

Object oriented programming can partially solve this problem by organizing data, and all the subprograms that manipulate that data, into a single location, or an object. In other words this means that the data and functions are integrated into data structures called classes. Encapsulation is used to package data with the functions that act on the data. The declaration of such an encapsulated unit is called a class, which refers to an abstract view of objects in the real world. Object-oriented programs typically restrict the programmer from haphazard access to the data. If a programmer using an object wishes to, for example, display or change the data, the only way of doing so is via a controlled access mechanism (a method of the class. A programmer writing a control routine in the main part of a program using OOP techniques simply sends a message to the object asking it to print, display, or change its data. All of the methods written with the class have open access to the data associated with an object of that class, but no part of a program constructed in the future, outside of the object, can change the data thereby possibly introducing mistakes or errors in the program. As Clarkson (1992) put it, "objects manipulate themselves; nothing reaches inside and stirs their contents around". These features allow us to easily modify and fix the code.

The following is a simple example that demonstrates encapsulation in Object oriented programming:

public class Box {
private int length;
private int width;
private int height;
public int getLength() {
return length;
}
public void setLength(int length) {
this.length = length;
}
public int getWidth() {
return width;
}
public void setWidth(int width) {
this.width = width;
}
public int getHeight() {
return height;
}
public void setHeight(int height) {
this.height = height;
}
}

=== [http://en.wikipedia.org/wiki/Reusability Reusability] ===
Reusability is achieved in Object Oriented programming through Inheritance. Inheritance is when one class inherits, or absorbs, the same fields and methods of another class, and adds necessary methods and fields to the new class. This lets developers maximize the use of application objects. In inheritance mechanism, data structures and behaviors are inherited. Without inheritance, every subclass would have to write the exact same fields and methods (because that class requires those fields and methods), which is time consuming and inefficient.
Developers can implement inheritance in two modes: single and multiple. Single inheritance allows the inheritance of information from a single object/class, whereas multiple inheritance allows objects to inherit information from two objects/classes simultaneously.
The more software you can borrow from others and incorporate in your own programs, the less you have to do yourself. There's more software to borrow in an object-oriented programming environment, because the code is more reusable. Collaboration between programmers working in different places for different organizations is enhanced, while the burden of each project is eased. Classes and frameworks from an object-oriented library can make inheritance possible.

In structured programming, the only possible way in which reusability can be implemented is the same subroutine can be called multiple times.

public class Bicycle {

public int cadence;
public int gear;
public int speed;

public Bicycle(int startCadence, int startSpeed, int startGear) {
gear = startGear;
cadence = startCadence;
speed = startSpeed;
}
public void setCadence(int newValue) {
cadence = newValue;
}
public void setGear(int newValue) {
gear = newValue;
}
public void applyBrake(int decrement) {
speed -= decrement;
}
public void speedUp(int increment) {
speed += increment;
}

}

A class declaration for a MountainBike class that is a subclass of Bicycle might look like this:

public class MountainBike extends Bicycle
{
public int seatHeight;
public MountainBike(int startHeight, int startCadence, int startSpeed, int startGear) {
super(startCadence, startSpeed, startGear);
seatHeight = startHeight;
}
public void setHeight(int newValue) {
seatHeight = newValue;
}
}

There are other added benefits of reusability such as:

* Reliability: The increased reusability of object-oriented code also increases its reliability. A class taken from a library is likely to have found its way into a variety of different applications and situations. The more the code has been used, the more likely it is that problems will have been encountered and fixed. Bugs that would have seemed strange and hard to find in your program might already have been tracked down and eliminated.

* Efficiency: The component developers are likely to be experts in their field and will have used the best possible algorithms and data structures.

* Time Savings: By relying upon existing components there is less software to develop and hence applications can be built quicker.

* Decreased maintenance effort: Using others' components decreases the amount of maintenance effort that the application developer needs to expend. The maintenance of the reused components is the responsibility of the component supplier.

* Consistency: Reliance on a library of standard components will tend to spread a consistency of design message throughout a team of programmers working on an application. The library is the basis of a standard that will lend coherency and conformity to the design process.

* Investment: Reusing software will save the cost of developing similar software from scratch. The investment in the original development is preserved if the developed software can be used in another project. The most reusable software tends to be that produced by the best developers. Reusing software is thus a way of preserving the knowledge and creations of the best developers.

=== Focus ===

Another major difference is that in structured programming functions are the primary focus of design. Data is of secondary importance. The structured programming approach results in many different parts of a program which have access to the data. The main control routine and any sub-routine may be coded to access the data directly, change it, and inadvertently introduce mistakes. If one programmer changes the representation of the data in the computer's memory by re-arranging fields within a record, other sub-routines in the program may need to be re-written and must then be re-tested to account for this change.

The OOP approach reverses the emphasis of data and functions used in structured programming. In OOP, programs pass messages to object methods that are conceptually packaged with an object's data. Object-oriented programming requires the analyst, designer and programmer to focus on objects rather than actions. This is a fundamental change from structured tools that focused on desired program actions with data playing a role in the shadows. Rosson and Alpert (1990) contrast the differences between conventional structured programming languages and OOP this way:

"Rather than invoking procedures to act on passive data, messages evoke object activity: A message sent to an object is a specification of some action, a request for the object to exhibit some behavior, or to supply some information. The action taken by the object is a function of its interpretation of the message and its internal state."

=== [http://en.wikipedia.org/wiki/Polymorphism_(computer_science) Polymorphism] ===

Polymorphism allows an object to be processed differently by data types and/or data classes. More precisely, it is the ability for different objects to respond to the same message in different ways. It allows a single name or operator to be associated with different operations, depending on the type of data it has passed, and gives the ability to redefine a method within a derived class.

For example, given the student and business subclasses of customer in a banking system, a programmer would be able to define different getInterestRate() methods in student and business to override the default interest getInterestRate() that is held in the customer class.

Also, in OOP, polymorphism permits the program to decide at run-time which of like-named methods derived from the same base class is the appropriate one to execute. Using this technique, also referred to as late-binding, a program coded to land "flying vehicles" can correctly land such flying vehicles as airplanes and helicopters without the need for traditional if-else or switch-case logic.

Polymorphism cannot be implemented in structured programming. Considering the same customer class example mentioned above, in structured programming, we would have to implement two different methods for computing the interest, one for the student and another for the businessman.

public class website {

String name;
String url;
String description;

public website(String n, String u, String d) {
name = n;
url = u;
description = d;
}

public website() {
name = "";
url = "";
description = "";
}

}

== What is a better choice ==

Whether we use object oriented or structured programming depends partly on our choice of language, but also on our design.
For example, the C language doesn’t offer any features for object oriented programming, but with enough discipline we can still write object-oriented code in C, such as the [http://mail.gnome.org/archives/gtk-app-devel-list/1998-November/msg00080.html GTK] windowing library.
On the other hand, we can write a Java program that completely fails to take advantage of Java’s OOP features, by putting all of our code in a single class and using classes with public members just as we would use structs in C.

{| class="wikitable"
|-
! Difference
! Structured Programming
! Object-Oriented Programming
|-
| Approach
| Top-down approach is followed
| Bottom-up approach is followed
|-
| Focus
| Focus is on algorithm and control flow.
| Focus is on object model.
|-
| Program Organization
| Program is divided into a number of sub modules, or functions, or procedures.
| Program is organized by having a number of classes and objects.
|-
| Design
| Functions are independent of each other.
| Each class is related in a hierarchical manner.
|-
| Function Call
| No designated receiver in the function call.
| There is a designated receiver for each message passing.
|-
| Data/methods
| Views data and functions as two separate entities.
| Views data and function as a single entity.
|-
| Maintenance
| Maintenance is costly.
| Maintenance is relatively cheaper.
|-
| Reusability
| Software reuse is not possible.
| Helps in software reuse.
|-
| Passing Arguments
| Function call is used.
| Message passing is used
|-
| Abstraction
| Function abstraction is used.
| Data abstraction is used.
|-
| Algorithm/Data
| Algorithm is given importance.
| Data is given importance.
|-
| Domain
| Solution is solution-domain specific.
| Solution is problem-domain specific.
|-
| Encapsulation
| No encapsulation. Data and functions are separate.
| Encapsulation packages code and data altogether. Data and functionalities are put together in a single entity.
|-
| Programmer
| Relationship between programmer and program is emphasized.
| Relationship between programmer and user is emphasized.
|-
| Technique
| Data-driven technique is used.
| Driven by delegation of responsibilities.
|}

== References ==

[1] Leonard H.Weiner(1978-02-01) [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=990555.990636&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "The roots of structured programming"]

[2] Edsger Dijkstra, [http://dl.acm.org.prox.lib.ncsu.edu/citation.cfm?id=1243380.1243381&coll=DL&dl=GUIDE&CFID=270598&CFTOKEN=91997490 "Notes on Structured Programming"]

[3] Peter Wegner, [http://dl.acm.org/citation.cfm?id=383004 "Concepts and paradigms of object-oriented programming"]

[4] Luiz Fernando Capretz, [http://dl.acm.org/citation.cfm?id=638778 "A brief history of the object-oriented approach"]

[5] [http://www.educational-computing.co.uk/OOPSample.doc OOP Sample]

[6] http://askville.amazon.com/Compare-Contrast-Structured-programming-Object-Oriented/AnswerViewer.do?requestId=2470573