Problem:
The term component is sometimes a difficult one to define. First provide a generic definition, and then provide more explicit definitions for object-oriented and traditional software. Finally, pick three programming languages with which you are familiar and illustrate how each defines a component.
Answer:
4633-10-1P SA: 9420
SR: 6376
The generic definition of a component is, a component is a modular building block for computer software. More formally, the OMG (Object Management Group) Unified Modeling Language Specification defines a component as “a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.”
In an object-oriented viewpoint, a component is a set of collaborating classes.
Each class with in a component has been fully elaborated to include all attributes and operations that are relevant to its implementation.
In the traditional view, a component is functional element of a program that includes processing logic, the internal data structures that are required to implement the processing logic, and an interface that enables the component to be invoked and data to be passed to it.
Each programming language defines a component in a different way.
In object-oriented languages (e.g., Java or Smalltalk) components are classes or objects. In traditional languages (e.g., C or FORTRAN) components are functions or procedures. In mixed languages like C++ components might be either functions or classes
Problem:
Why are control components necessary in traditional software and generally not required in object-oriented software?
Answer:
4633-10-2P SA: 9420
SR: 6376
A control component in traditional software coordinates the invocation of all other problem domain components. But object oriented software focuses on the elaboration of design classes that come from both the problem and infrastructure domain. In this view, each class within a component has been fully elaborated to include all attributes and operations that are relevant to its implementation. So the control components are not needed in the object oriented software.
Problem:
Describe the OCP in your own words. Why is it important to create abstractions that serve as an interface between components?
Answer:
Open – closed principle (OCP):
In this, the designer should specify the component in a way that allows it to be extended without the need to make internal modifications to the component itself.
The designer creates abstractions that serve as a buffer betaken the functionality that is likely to be extended and the design class itself.
A module should be open for extension but closed modification.
Problem:
Describe the DIP in your own words. What might happen if a designer depends too heavily on concretions?
Answer:
Dependency inversion principle (DIP):
DIP is “depend on abstractions do not depend on concretions”. Abstractions are the place where a design can be extended with out great complication. The more a component depends on there concrete components, then its (father than on abstractions such as an interface), the more difficult it will be external.
Problem:
Select three components that you have developed recently and assess the types of cohesion that each exhibits. If you had to define the primary benefit of high cohesion, what would it be?
Answer:
In the context of component-level design for object-oriented systems, cohesion implies that a component/class encapsulates only attributes and operations that are closely related to one another and to the class or component itself.
High cohesive are insulated from relying on services provided by other components will make their implementation and maintenance of easier.
Temporal:
Operations that are performed to reflect a specific behavior or state.
Ex: an operation performed at start up or all operations performed when an error is detected.
Procedural cohesion:
Elements involved in different but sequential activities, each on different data.
Sequential cohesion:
Components or operations are grouped in a manner that allows one to be invoked immediately after the preceding one was invoked, even when there is no data passed between them.
Problem:
Select three components that you have developed recently and assess the types of coupling that each exhibits. If you had to define the primary benefit of low coupling, what would it be?
Answer:
Coupling is a qualitative measure of degree to which classes are concerted to one another,
as classes become more independent, coupling increases.
An important objective in component level design is to keep coupling as low as possible.
Common coupling:
Common coupling occurs when a number of components all make use of a global variable. Although this is sometimes necessary, Common coupling can lead to uncontrolled error propagation and unforeseen side effects when changes are made.
Control coupling:
Control coupling occurs when operation A ( ) invokes operation B ( ) and passes a control flog to B. the control flag then ‘directs’ logical flow with B. the problem with this form of coupling is that an unrelated change in B can result in the necessity to change the meaning of the control flag that A passes.
External coupling:-
External coupling occurs when a component communicates or collaborates with infrastructure components.
Even this type of coupling is necessary; Then it should be limited to a small number of components or classes with in a system.
Problem:
Is it reasonable to say that problem domain components should never exhibit external coupling? If you agree, what types of component would exhibit external coupling?
Answer:
Consider the statement,
“Problem domain components should never exhibit external coupling”.
Strongly, I agree with this statement. Because, external coupling occurs when two modules share an externally by component communicates or collaborates (imposed data format, communication protocol, or device interface) with infrastructure components.
Example: database.
Coupling increases the complexity and obscurity of the interface between modules. In this, External coupling is type of coupling.
It is very necessary to component communication, and it should be limited to a small number of components or classes with in system.
To exhibit modules in the external coupling, modules should be share direct access to the same device (or) tied to the same part of the environment external to software. So, for this type of coupling, software must communicate internally and externally. Hence, coupling is a fact of life.
The designer should work to reduce coupling whenever possible and understand the ramification of high coupling when it can not be avoided.
Problem:
Develop (1) an elaborated design class, (2) interface descriptions, (3) an activity diagram for one of the operations within the class, and (4) a detailed statechart diagram for one of the SafeHome classes that we have discussed in earlier chapters.
Answer:
Problem:
Are stepwise refinement and refactoring the same thing? If not, how do they differ?
Answer:
Stepwise refinement and factoring are not the same things.
Factoring is the process of distributing the control a decision-making of the system so that the top-level modules perform control functions and the low-level modules perform all input, processing, and output work
Stepwise refinement program is developed by successively refining levels of procedural detail. For traditional software development they are very similar.
Stepwise refinement technique for writing modules which are coiner, correct easy to read, modify, understand.
Factoring avoid duplicate code not possible.
Factoring modifications are differing from stepwise refinement.
Problem:
What is a WebApp component?
Answer:
4633-10-10P SA: 9420
SR: 6376
A WebApp component is defined either as
• A well-defined organized function that manipulates content or provides computational or data processing for an end user or
• A cohesive package of content and functionality that provides the end user with some required capability.
Therefore, component-level design for WebApps often incorporates elements of content design and functional design.
Problem:
Select a small portion of an existing program (approximately 50 to 75 source lines). Isolate the structured programming constructs by drawing boxes around them in the source code. Does the program excerpt have constructs that violate the structured programming philosophy? If so, redesign the code to make it conform to structured programming constructs. If not, what do you notice about the boxes that you’ve drawn?
Answer:
592-11-16P SA Code: 4475
SR Code: 4578
Structured Programming uses only three constructs. Those are
Sequence (statements, blocks)
Selection (if, switch)
Iteration (loops like while and for)
For Example: Consider the Binary Tree Construction program. This may follows the Structured Programming Constructs.When adding an element to the tree, if the element is in the tree already, it is not added. The proper place to insert at is searched recursively by calling the insert method.
The insertion method snippet:
Public void add (E element) {
if (root == null && element != null) {
root = new Node(element);
size++;
} else if (element != null) {
root = insert(root, element);
}
}
The recursive insertion method takes two parameters: a node to search from and the element to add. It returns the node including the inserted new element. When the value is already in the tree, nothing is done. For a more sophisticated tree, we could add the new element, count frequencies, etc.
if (compare == 0)
{
return result;
}
In case the new value needs to be inserted in the left subtree:
//Left subtree
if (compare > 0) {
if (result.left != null) {
result.left = insert (result.left, value);
} else {
result.left = new Node(value);
size++;
}
}
In case, the new value needs to be inserted in the right subtree:
else if (compare < 0) {
if (result.right != null) {
result.right = insert (result.right, value);
} else {
result.right = new Node(value);
size++;
}
}
Search for a value in the tree, return the element if found or null if the element is not in the tree. Iteratively search a value in the tree, starting from the root, continuing either in the left or in the right subtree. Return the element, if found:
Read the element from the tree:
public E get(E key) {
if (root == null)
return null;
Node node = root;
int compareResult;
while ((compareResult = node.value.compareTo (key)) != 0) {
if (compareResult > 0) {
if (node. left != null)
node = node. left;
else
return null;
} else {
if (node.right != null)
node = node.right;
else
return null;
}
}
return node. value;
}
Create a List from the tree and return it:
public List toList() {
List result = new ArrayList();
treeToList(root, result);
return result;
}
Recursive preorder traversal of the tree, saving the values to the array:
Private void treeToList(Node node, List goal) {
if (node != null) {
treeToList(node.left, goal);
goal.add(node.value);
treeToList(node.right, goal);
}
}
Problem:
All modern programming languages implement the structured programming constructs. Provide examples from three programming languages.
Answer:
The structured programming constructs are sequence, condition, and repetition. Programming languages such as C, C++, Java are follows these constructs.
Example from ‘C’ programming language:
void main()
{
/* sequence */
int a=5, b=2, c;
int sum =0, i;
/* Basic Arthmetic operations
c = a+b;
printf("sum of a,b is :%d',c);
c= a-b;
printf("difference of a,b is :%d',c);
/* condition logic */
/* greater of 2 */
if (a>b)
printf("%d is greater than %d",a,b);
else
printf("%d is greater than %d",b,a);
/* repetition */
/* sum of 1 to 5 */
for( i=0;i<=5;i++)
sum += i;
printf("sum of 1 to 5 is %d", sum);
}
Example from ‘C++’ programming language:
void main()
{
int a=5, b=2, c; /* sequence */
int sum =0, i;
/* Basic Arthmetic operations
c = a+b;
Cout<<"sum of a,b is"<< sum;
c= a-b;
Cout<<"difference of a,b is<;<>
/* condition logic */
/* greater of 2 */
if (a>b)
Cout< <
else
Cout< <
/* repetition */
/* sum of 1 to 5 */
for( i=0;i<=5;i++)
sum += i;
Cout<
}
Example from java programming language:
void main()
{
/* sequence */
int a=5, b=2, c;
int sum =0, i;
/* Basic Arthmetic operations
c = a+b;
System.out.println("The sum is: " + sum);
c= a-b;
System.out.println("Difference of a,b is: " + sum);
/* condition logic */
/* greater of 2 */
if (a>b)
{
System.out.println("a is greater than b");
}
else
{
System.out.println("b is greater than a");
}
/* repetition */
/* sum of 1 to 5 */
for(i=0;i<=5;i++)
sum += i;
System.out.println("total of 1 to 5 is: " + sum);
}
Problem:
Select a small coded component and represent it using an activity diagram.
Answer:
Problem:
Why is “chunking” important during the component-level design review process?
Answer:
4633-10-14P SA: 4475
SR: 6376
Chunking is the process to the software in a way that allows us to review the details of the design for correctness and consistency. Content design at the component level focuses on content objects and the manner in which they may be packaged for presentation to a WebApp end user.
Chunks allow a reader to recognize procedural elements of a model, rather than reading the design or code line by line. Understanding is enhanced when readily recognizable patterns are encountered. As chunks provide better readability and understandability, they help in making the component-level design review process easier. Hence it is important in component-level design review process.
Solution: CHAPTER14: COMPONENT-LEVEL DESIGN
14.1 Component-level design defines the data structures, algorithms, interface characteristics, and communication mechanisms allocated to each software component. In object-oriented languages (e.g. Java or Smalltalk) components are classes or objects. In traditional languages (e.g. C or Fortran) components are functions or procedures. In mixed languages like C++ components might be either functions or classes.
14.2 Like object-oriented components, traditional software components are derived from the analysis model. In this case, the analysis model is mapped into a module hierarchy. Control components (modules) reside near the top of the hierarchy (architecture) and problem domain components tend to reside toward the bottom of the hierarchy. To achieve effective modularity, design concepts like functional independence are applied as components are elaborated.
14.3 The Open-Closed Principle (OCP) states module [component] should be open for extension but closed for modification. The designer creates the designer should specify the component in a way that allows it to be extended (within the functional domain that it addresses) without the need to make internal (code abstractions that serve as a buffer between the functionality that is likely to be extended and the design class itself.
14.4 Dependency Inversion Principle (DIP) states, depend on abstractions. Do not depend on concretions. The more a component depends on other concrete components (rather than on abstractions such as an interface), the more difficult it will be to extend.
14.5 Within the context of component-level design for object-oriented systems, cohesion implies that a component or class encapsulates only attributes and operations that are closely related to one another and to the class or component itself. Components that highly cohesive are insulated from relying on services provided by other components will make their implementation and maintenance of easier.
14.6 Coupling is a qualitative measure of the degree to which classes are connected to one another. As classes (and components) become more interdependent, coupling increases. A benefit of low coupling if the ease among components is the ease with which components can be modified without affected the behavior of other components.
14.7 External coupling occurs when a component communicates or collaborates with infrastructure components (e.g., operation system functions, database capability, telecommunication functions). Although this type of coupling is necessary, it should be limited to a small number of components or classes within a system. Software must communicate internally and externally. Therefore, coupling is a fact of life. However, the designer should work to reduce coupling whenever possible and understand the ramifications of high coupling when it cannot be avoided.
14.8 Answers will vary
14.9 Factoring is the process of distributing the control a decision-making of the system so that the top-level modules perform control functions and the low-level modules perform all input, processing, and output work. In stepwise refinement a program is developed by successively refining levels of procedural detail. For traditional software development they are very similar.
14.10 WebApp component is defined is either a:
o well-defined cohesive function manipulates content or provides computational or data processing for an end- user or
o cohesive package of content and functionality that provides the end-user with some required capability
14.11 Answers will vary
14.12 Answers will vary
14.13 Answers will vary
14.14 People can on keep track of a small number (5 to 9) of things at a time in short term memory. Chunking allows reviewers to combine related concepts into larger pieces or bigger chunks. The components can serve as chunks (if the components are highly cohesive and loosely coupled) making it easier for reviewers to keep track of the interactions of several components during a design review rather than a large number of individual classes and their methods.