Mobiprep has created last-minute notes for all topics of Software Engineering to help you with the revision of concepts for your university examinations. So let’s get started with the lecture notes on Software Engineering.
7. UML
Our team has curated a list of the most important questions asked in universities such as DU, DTU, VIT, SRM, IP, Pune University, Manipal University, and many more. The questions are created from the previous year's question papers of colleges and universities.
(a)Requirements analysis and specification (b)Software Design
Question 1) State Requirement Elicitation Process
Answer) It is stated as follows:
Question 2) Compare relative advantages of the object-oriented and function-oriented approaches to software design.
Answer)
Object-oriented software design | Function-oriented software design |
The basic abstractions are not the real-world functions but are the data abstraction where the real world entities are represented. | The basic abstractions, which are given to the user, are real world functions. |
Functions are grouped together on the basis of the data they operate since the classes are associated with their methods. | Functions are grouped together by which a higher-level function is obtained. |
In this approach the state information is not represented is not represented in a centralized memory but is implemented or distributed among the objects of the system. | In this approach the state information is often represented in a centralized shared memory. |
It is a bottom up approach. | It is a top down approach. |
Begins by identifying objects and classes. | Begins by considering the use case diagrams and the scenarios. |
We decompose at class level. | In function-oriented design we decompose in function/procedure level. |
This approach is mainly used for evolving systems which mimics a business or business case. | This approach is mainly used for computation sensitive application. |
Question 3) State Software Requirements Characteristics
Answer) A complete Software Requirement Specifications must be:
Clear
Correct
Consistent
Coherent
Comprehensible
Modifiable
Verifiable
Prioritized
Unambiguous
Traceable
Credible source
Question 4) What do you mean by the terms cohesion and coupling in the context of software design?
Answer) Cohesion is the indication of the relationship within a module. The concept of intra-module (or) Cohesion is defined as the degree to which all elements of a module, class, or component work together as a functional unit. Cohesion has many types but usually highly cohesion is good for software.
Coupling is also the indication of the relationships between modules (or) is defined as the degree of interdependence between two or more classes, modules, or components. It is the concept of Inter-module. Tight coupling is bad, and loose coupling is good.
Question 5) What is an ADT? What advantages accrue when a software design technique is based on ADTs?
Answer) Abstract data types are an instance of a general principle in software engineering, which goes by many names with slightly different shades of meaning. Here are some of the names that are used for this idea:
Abstraction: Omitting or hiding low-level details with a simpler, higher-level idea.
Modularity: Dividing a system into components or modules, each of which can be designed, implemented, tested, reasoned about, and reused separately from the rest of the system.
Encapsulation: Building walls around a module (a hard shell or capsule) so that the module is responsible for its own internal behavior, and bugs in other parts of the system can’t damage its integrity.
Information hiding: Hiding details of a module’s implementation from the rest of the system, so that those details can be changed later without changing the rest of the system.
Separation of concerns: Making a feature the responsibility of a single module, rather than spreading it across multiple modules.
Question 6) What is the difference between the functional and the non-functional requirements of a system?
Answer)
Functional Requirements | Non-Functional Requirements |
User specifies functional requirements | Technical people will provide the requirements. e.g. Architect, Technical leaders and software developers. |
It is mandatory to provide functional requirements. | It is not mandatory to provide non-functional requirements |
Easy to capture | Hard to capture |
Use case diagrams are used to capture. | Quality attribute is used to capture |
End result is Product feature | End result is Product properties |
It is defined at component level. | It is applied to a system as a whole |
It focuses on user requirements. | It concentrates on the user's expectation. |
It helps you verify the functionality of the software. | It helps you to verify the performance of the software. |
Functional Testing like System, Integration, End to End, API testing, etc are done | Non-Functional Testing like Performance, Stress, Usability, Security testing, etc are done. |
Test Execution is done before non-functional testing. | After the functional testing |
Usually easy to define. | Usually more difficult to define. |
Example:
| Example:
|
Question 7) State Software Metrics and Measures.
Answer) Software Metrics provide measures for various aspects of software processes and software products.
According to Tom DeMarco, a (Software Engineer), “You cannot control what you cannot measure.”
Let us see some software metrics:
Size Metrics -
LOC (Lines of Code)
Function Point Count
Complexity Metrics - McCabe’s Cyclomatic complexity
Quality Metrics - Defects, their types and causes, consequence, intensity of severity and their implications.
Process Metrics - The company standards and the performance of development are software process metrics.
Resource Metrics - Effort, time and various resources used, represents metrics for resource measurement.
Question 8) What do you understand by the problems of over specification, forward reference, and noise in an SRS document?
Answer
Over specification
It occurs when the analyst tries to address the "how to" aspects in the SRS document. It limits the imagination of the developers/designers to come up with a good solution.
Forward references
It happens when the analyst refers to the aspects which are discussed much later in the SRS, this causes readability issues in the document.
Noise
Noise refers to the presence of material not directly relevant to the software development process. It is hardly of any use to the software developers and would unnecessarily clutter the SRS document, diverting the attention from the crucial points.
Comments