CS711 - Sofware Design
Course Page
Mcqs
Q & A
Video
Downloads
Short Question & Answers
Q1: Describe the Drawback of V-Model
Spring 2018 – Mid
  1. Not suitable for bigger and complex projects
  2. Not a good option If Requirement changes frequently
  3. The client sees the only final project, not intermediate modules
  4. Don’t scope for risk management and risk mitigation
  5. Very rigid and least flexible
  6. Software is developed during the implementation phase, so no early prototypes of the software are produced
  7. If any changes happen in midway, then the test documents along with requirement documents has to be updated
Q2: What are the Main Features of V-Model
Spring 2018 – Mid
  1. Simple and easy to use
  2. Testing activities like planning, test designing happens well before coding. This saves a lot of time. Hence higher chance of success over the waterfall model
  3. Proactive defect tracking – that is defects are found at early stage
  4. Avoids the downward flow of the defects
  5. Works well for small projects where requirements are easily understood
  6. Progress goes in very systematic way
  7. Best suitable for small and medium size projects
  8. Testing starts from requirement phase
  9. Easy to keep track on progress
Q3: Describe the Principles of XP
Spring 2018 – Mid
Most researchers denote 5 XP principles as:
  1. Rapid feedback: Team members understand the given feedback and react to it right away
  2. Assumed simplicity: Developers need to focus on the job that is important at the moment and follow YAGNI (You Ain’t Gonna Need It) and DRY (Don’t Repeat Yourself) principles
  3. Incremental changes: Small changes made to a product step by step work better than big ones made at once
  4. Embracing change: If a client thinks a product needs to be changed, programmers should support this decision and plan how to implement new requirements
  5. Quality work: A team that works well, makes a valuable product and feels proud of it
Q4: Describe the Software Crises History
Spring 2018 – Mid
Software crisis was a term used in the early days of computing science. The term was used to describe the impact of rapid increases in computer power and the complexity of the problems which could be tackled. In essence, it refers to the difficulty of writing correct, understandable, and verifiable computer programs. The term "software crisis" was coined by F. L. Bauer at the first NATO Software Engineering Conference in 1968 at Garmisch, Germany.
Q5: What are the Advantages and Disadvantages of Waterfall Model
Spring 2018 – Mid
Advantages of waterfall model
  1. This model is simple and easy to understand and use
  2. It is easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process
  3. In this model phases are processed and completed one at a time. Phases do not overlap
  4. Waterfall model works well for smaller projects where requirements are clearly defined and very well understood
Disadvantages of waterfall model
  1. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage
  2. No working software is produced until late during the life cycle
  3. High amounts of risk and uncertainty
  4. Not a good model for complex and object-oriented projects
  5. Poor model for long and ongoing projects
  6. Not suitable for the projects where requirements are at a moderate to high risk of changing
When to use the waterfall model
  1. This model is used only when the requirements are very well known, clear and fixed
  2. Product definition is stable
  3. Technology is understood
  4. There are no ambiguous requirements
  5. Ample resources with required expertise are available freely
  6. The project is short
Q6: Describe the Layer Rules
Spring 2018 – Mid
  1. From a high-level viewpoint the solution is extremely simple. Structure your system into an appropriate number of layers and place them on top of each other. Start at the lowest level of abstraction-ca11 it Layer 1
  2. This is the base of your system. Work your way up the abstraction ladder by putting Layer Jon top of Layer J -1 until you reach the top level of functionality-call it Layer N
  3. Note that this does not prescribe the order in which to actually design layers, it just gives a conceptual view
  4. It also does not prescribe whether an individual Layer J should be a complex subsystem that needs further decomposition, or whether it should just translate requests from Layer J + I to requests to Layer J -1 and make little contribution of Its own
  5. It is however essential that within an individual layer all constituent components work at the same level of abstraction
  6. Most of the services that Layer J provides are composed of services provided by Layer J -I. In other words, the services of each layer implement a strategy for combining the services of the layer below in a meaningful way
  7. In addition, Layer J's services may depend on other services in Layer J. Layer can request for services from exactly one layer below it and can respond to a request of a layer exactly one layer above it
  8. The main structural characteristic of the Layerspattern is that the services of Layer J are only used by Layer J + I-there are no further direct dependencies between layers
  9. This structure can be compared with a stack, or even an onion. Each individual layer shields its lower layers from direct access by higher layers
For example:
  1. Total Layers = N = 3
  2. Legal Request = N-1
  3. Legal Response = N+ 1
Q7: Explain the Elaboration Phase of Rational Unified Process Model
Spring 2018 – Mid
The purpose of the elaboration phase is to analyze the problem domain, establish a sound architectural foundation, develop the project plan, and eliminate the highest risk elements of the project. To accomplish these objectives, you must have the “mile wide and inch deep” view of the system. Architectural decisions have to be made with an understanding of the whole system: its scope, major functionality and nonfunctional requirements such as performance requirements. It is easy to argue that the elaboration phase is the most critical of the four phases.

At the end of this phase, the hard “engineering” is considered complete and the project undergoes its most important day of reckoning: the decision on whether or not to commit to the construction and transition phases. For most projects, this also corresponds to the transition from a mobile, light and nimble, low-risk operation to a high-cost, high-risk operation with substantial inertia. While the process must always accommodate changes, the elaboration phase activities ensure that the architecture, requirements and plans are stable enough, and the risks are sufficiently mitigated, so you can predictably determine the cost and schedule for the completion of the development. Conceptually, this level of fidelity would correspond to the level necessary for an organization to commit to a fixed-price construction phase.

In the elaboration phase, an executable architecture prototype is built in one or more iterations, depending on the scope, size, risk, and novelty of the project. This effort should at least address the critical use cases identified in the inception phase, which typically expose the major technical risks of the project. While an evolutionary prototype of a production-quality component is always the goal, this does not exclude the development of one or more exploratory, throwaway prototypes to mitigate specific risks such as design/requirements trade-offs, component feasibility study, or demonstrations to investors, customers, and end-users.
Q8: Communicational Cohesion with Example.
Fall 2016 – Mid
A communicationally cohesive module is one which performs several functions on the same input or output data. For example, obtain author, title, or price of book from bibliographic record, based on a passed flag. (Note: The functions in this example could be performed independently of each other and should be separated for greater flexibility. Maintainability is usually improved when you separate a communicationally cohesive module into functionally cohesive modules.) Communicational cohesion is rare in object-oriented systems since object-oriented designs tend to stress polymorphism.
Q9: Content Coupling with Example.
Fall 2016 – Mid
This is also known as ``Pathological Coupling'', a highest level of coupling and occurs if there are two (or more) modules and if one refers to the ``inside'' - the ``internal'' or ``private'' part - of the other in some way.
  • Module A ``branches'' or ``falls through'' into Module B (by containing a GOTO statement that transfers control somewhere into the middle of Module B);
  • Module A refers to, or changes, Module B's internal (and, again, ` `private'') data
  • Module A changes one of the statements in Module B's object code.
Q10: Inheritance with Example
Fall 2016 – Mid
Spring 2018 – Mid
Inheritance is a mechanism in which one class acquires the property of another class. For example, a child inherits the traits of his/her parents. With inheritance, we can reuse the fields and methods of the existing class. Hence, inheritance facilitates Reusability and is an important concept of OOPs. There are Various types of inheritance in Java:
  1. Single Inheritance: In Single Inheritance one class extends another class (one class only).
  2. Multiple Inheritance: In Multiple Inheritance, one class extending more than one class. Java does not support multiple inheritance.
  3. Multilevel Inheritance: In Multilevel Inheritance, one class can inherit from a derived class. Hence, the derived class becomes the base class for the new class.
  4. Hierarchical Inheritance: In Hierarchical Inheritance, one class is inherited by many sub classes.
  5. Hybrid Inheritance: Hybrid inheritance is a combination of Single and Multiple inheritance.
Inheritance in Java:
  • In Java, when an "Is-A" relationship exists between two classes we use Inheritance
  • The parent class is termed super class and the inherited class is the sub class
  • The keyword "extend" is used by the sub class to inherit the features of super class
  • Inheritance is important since it leads to reusability of code
Java Inheritance Syntax:
 

class subClass extends superClass { 
     //methods and fields
}

Java Inheritance Example:
 

class Doctor {
     void Doctor_Details() {
          System.out.println("Doctor Details...");
     }
}

class Surgeon extends Doctor {
     void Surgeon_Details() {
          System.out.println("Surgen Detail...");
     }
}

public class Hospital {
     public static void main(String args[] ) {
          Surgeon s = new Surgeon();
          s.Doctor_Details();
          s.Surgeon_Details();
     }
}


Course Instructor

Sheraz Pervaiz
MS in Software Technology Stuttgart University of Applied Sciences, Germany
Books

Anti- Patterns, Identification, Refactoring, and Management by Phillip A. Laplante

Design Patterns Elements of Reusable Object Oriented Software by Erich Gamma

Head First Design Pattern by Eric T Freeman

Pattern Oriented Software Architecture by Frank Buschmann

Software Architecture Design Pattern in Java by Partha Kuchana

The Design Pattern – Java Companion by James W. Cooper