SOFTWARE MODELLING THEORY

1. INTRODUCTION AND SOFTWARE LIFE CYCLE

1. What are the essential characteristics of software engineering?
i)
Software engineering concerns the development of large programs;
ii)
The central theme is mastering complexity;
iii)
Software evolves;
iv)
The efficiency with which software is developed is of crucial importance;
v)
Regular cooperation between people is an integral part of programming-on-thelarge;
vi)
The software has to support its users effectively.
2. What is a feasibility study? Which SLC models cover it and in which phase?
A feasibility study is a part of requirements engineering which assesses whether there is a
solution to the problem which is both economically and technically feasible.
The result of this activity is laid down in the requirements specifications.
3. Explain the two concepts of verification and validation. Explain if and how they differ
from testing.
Testing comes in two flavours:
testing that the transition between SLC phases is correct (verification);
checking whether the development is on the right track w.r.t. fulfilling the clients
requirements (validation).
4. Explain the different types of maintenance in software engineering.
perfective (50%) new or changed user requirements which affect functional
requirements;
adaptive (25%) adapt to platform changes;
corrective (21%) fixing errors, ONLY REAL MAINTENANCE;
preventive (4%) increase reliability or maintainability to prevent errors.
5. What is the relative effort typically spent in SLC phases?
specification 10%;
reqs. engineering 10%;
design 15%;
coding 20%;
testing 45%.
6. Explain the 40-20-40 rule of thumb in software engineering.
design 40%;
coding 20%;
testing 40%.
7. What is the difference between maintenance and evolution?
Only corrective maintenance (21%) can be deemed as real maintenance, resolving errors,
while the other 3 types of maintenance (79%) imply the evolution of the application.

8. What is the typical distribution of maintenance activities in the software life cycle?
See Question 4.
9. Why are traditional SLC models called heavyweight?
Traditional SLC models are called heavyweight because of the emphasis placed on the
process, planning-driven because of the emphasis put on an upfont plan for the whole
process and document-driven because of the emphasis placed on documentation.
10. The waterfall SLC model is considered unrealistic: why is that?
The waterfall SLC model is considered unrealistic because, in many software development
projects, the strict sequencing of phases advocated by the waterfall model is not actually
obeyed.
11. Question about selecting a specific SLC model to a specific scenario.
12. Explain the difference between the waterfall model and the V-model.
Vezi caiet (scheme).
13. What is the major motivation behind the Agile SLC models as compared to the traditional
ones?
As opposed to traditional methods, where, once the contract has been signed, it is the
development teams job to deliver the functionality as laid down in the contract, thus
making the project difficult to change direction, agile methods assume change is inevitable
and focus on delivering value to the customer as quickly as possible.
14. Explain the four key values of the agile movement.
Individuals and interactions over processes and tools;
Working software over comprehensive documentation;
Customer collaboration over contract negotiation;
Responding to change over following a plan.
15. Explain the two types of prototyping. Why is it considered an agile SLC model?
In throwaway prototyping, the prototyping phase has been separated by the
production phase, which follows a waterfall-like model;
In evolutionary prototyping, the last version developed which satisfies the user is
the product to be delivered.
16. Explain the essential characteristics of incremental development.
software is developed in small increments;
the waterfall model is employed in each phase;
the user is closely involved in directing the next steps;
incremental development prevents over-functionality.
17. What is Rapid Application Development? Explain its phases and its characteristics.
evolutionary development with time boxes: fixed time frames within activities are
done;
time frame is decided upon first, then one tries to realize as much as possible within
that time frame;
other elements: Joint Requirements Planning (JRP) and Joint Application Design
(JAD) workshops within which users participate.

18.

19.

20.

21.

22.

23.

24.

requirements prioritization within MoSCoW triangle (Must Have, Should Have,

Could Have, Wont Have);
development in a SWAT team: Skilled Workers with Advanced Tools.
What requirements prioritization approaches do you know? In what types of SLC models
are they typically used?
The Kano model and MoSCoW, used in agile models (the latter typically in RAD)
Explain the Kano model.
The Kano model is a requirements prioritization scheme which classifies user preferences
into 5 categories:
Attractive customer is more satisfied if these requirements are met, but not less
satisfied otherwise;
Must-be customer will be dissatisfied if these requirements are not met, but his
satisfaction will not be better than neutral;
One-dimensional satisfaction is proportional to how many requirements in this
category are met;
Indifferent;
Reverse clients requirements are the opposite of what the analyst thought;
Questionable.
What are the four major types of activity in requirements engineering?
Elicitation: understand the problem, interact with domain experts, detect
conflicting requirements;
Specification: describe the problem (product-to-be), select the right modeling
notation;
Validation: agree on the problem description;
Negotiation: find a compromise for conflicting requirements and resources.
What is the requirements elicitation?
Requirements elicitation is a type of activity in requirements engineering which involves
understanding the problem, interacting with domain experts and detecting conflicting
requirements.
Explain one requirements elicitation technique of your choice. When would such
technique be most appropriate?
Ethnographic methods are more likely to uncover tacit knowledge than most other
elicitation techniques as they focus on studying people in their natural setting, thus taking
into account the social and organizational environment when analyzing tasks.
What are non-functional requirements (NFRs)? How do they differ from functional
requirements (FRs)? Add an example for both FR and NFR.
An NFR describes how the system should behave, it is a constraint upon the system
behavior. As opposed to NFRs, FRs describe what the system should do.
What is the main innovation introduced by the Rational Unified Process (RUP) as
compared to its predecessor SLC models?

RUP is an iterative approach for object-oriented systems which strongly embraces use cases
for modeling requirements.
2. Requirements Engineering and Modeling Software Requirements
25. Explain the main goal of the four requirements engineering activities of requirements
elicitation, specification, validation and negotiation.
See Question 20.
26. In which phase of the RUP software lifecycle model do we typically carry out requirements
modeling?
Requirements are modeled during the Inception and Elaboration phases of RUP.
27. In which phase of the RAD software lifecycle model do we typically carry out requirements
modeling?
Requirements are modeled during the Requirements planning phase of RAD.
28. Describe the requirements elicitation technique called task analysis.
Task analysis is a technique to obtain a hierarchy of tasks and subtasks to be carried out by
people working in the domain. Any of the other techniques discussed may be used to get
the necessary information to draw this hierarchy. There are no clear-cut rules as to when to
stop decomposing tasks. A major heuristic is that at some point users tend to refuse to
decompose tasks any further.
29. Describe the requirements elicitation technique called scenario-based analysis.
Instead of looking for generic plans as in interviews or task analysis, the analyst may study
instances of tasks. A scenario is a story which tells us how a specific task instance is
executed. The scenario can be real or artificial. An example of a real scenario is that the
analyst observes how a library employee handles an actual user request.
30. Describe the requirements elicitation technique called task brainstorming.
No fucking idea..
31. In which circumstances is ethnography a viable elicitation technique?
See Question 22.
32. What is goal-oriented requirements engineering?
Goal-oriented requirements engineering are requirements engineering which focus on the
objectives a system should achieve through cooperation of actors in the intended software
and in the environment.
33. What does MoSCoW stand for?
See Question 17.
34. What is UML? What is the main innovation introduced by UML?
The Unified Modeling Language is a modeling language used in software engineering which
provides a standard way to visualize the design of a system.
Its main innovations are its diagrams:
Class diagram Information model, structural view, static
Case diagram functional, interaction specification, dynamic

35.

36.

37.

38.
39.
40.
41.

42.

Activity diagram modeling workflow, functional use of cases, dynamic

State diagram modeling objects states, functioning of use cases, logical view,
dynamic
Define the following terms: object, state, attribute, message and inheritance.
object: instance of a class;
state: condition in the life of an object;
attribute: property;
message: ???;
inheritance: reuse of properties.
Explain the difference between specialization-generalization and the whole-part relation.
Specialization-generalization defines an is a relationship between objects, a hierarchical
relationship, while whole-part represents aggregation, a has a relationship.
Explain the difference between a class diagram and a state-machine diagram.
A class diagram depicts how objects are defined by their attributes and relations, while a
state-machine diagram depicts the sequence of states that an object can go through.
What does an activity diagram represent in a software requirements specification?
An activity diagram represents workflows of stepwise activities and actions.
What type of view does a class diagram provide?
Structural.
What type of view does a use case diagram provide?
Behavioral.
For what type of software systems would you use state machine diagrams to model
functional requirements?
Dynamic.
For what type of software systems is data modeling via UML class diagram suitable?
Static.
3. Checking For Quality Requirements Models

43. What is requirements creep? Also, explain how requirements management activities
help to avoid it.
Requirements creep refers to the phenomenon of requirements changing after the
requirements phase has ended.
Requirements identification involves uniquely identifying each requirement;
Requirements change management allows applying rules and procedures of
configuration management by viewing each requirement as a configuration item;
Requirements traceability allows tracing when requirements are realized in the
code (forward traceability) and why certain solutions are chosen (backwards
traceability)
44. Explain the notion of internal consistency for requirements specification.

45.

46.

47.

48.

A requirements specification is internally consistent if its components do not contradict

each other.
Define two quality criteria relevant to ensure good quality of requirements model. Add a
modeling example (using any requirements modeling notation you studied in this course)
to illustrate them.
No idea..
Explain the notion of verifiability for requirements specifications.
There must be a finite process to determine whether requirement specifications have been
met.
How can you ensure that quality requirements are verifiable in a requirements
specification?
Avoid vague/loose/general quality requirements (e.g.: loading time should be around..)
Explain the notion of traceability for requirements specifications. Why is requirements
traceability important? For which SLC phases?
Requirements traceability allows tracing when requirements are realized in the code
(forward traceability) and why certain solutions are chosen (backwards traceability). It is
important during Verification and Validation of the Testing phase.
4. Modeling software design

49. Give a definition of software design.

The Software Design is a blueprint of the system into a set of interacting modules or
components. It describes how a system can support the functional requirements, and how
well it does fulfill the non-functional and quality requirements.
50. When are design activities carried out in heavyweight SLC models?
During the Design phase.
51. When are design activities carried out in Rapid Application Development?
During the Application Design phase.
52. When are design activities carried out in the Rational Unified Process model?
During the Elaboration phase.
53. Define procedural abstraction and data abstraction. Also, provide an example for both.
Procedural abstraction focuses on decomposing the problem into sub-problems until each
sub-problem has a standard solution. This technique may result in applications that are too
difficult to adapt and too hard to comprehend. Data abstraction involves finding a hierarchy
in the programs entities, identifying relations among them and identifying object-attribute
operations.
54. What is the difference between procedural abstraction and data abstraction?
See Question 53.
55. Explain the Model-View-Controller design pattern.

The MVC design pattern aids interactive systems in separating concerns between
computational elements and those that handle I/O. The Model encapsulates the systems
data and operations on that data. It is independent on how data is represented or how input
is done. The View displays data obtained from the Model. The Controller handles input
actions which may cause the controller to send requests to the Model.
5. Modeling service oriented software design with SoaML

56. What is a service? And what is a software service?

A service:
is a logical representation of a repeatable business activity that has a specified;
outcome (e.g. check customer data, provide weather report, deliver pizza,
provide higher level education);
is self-contained (state-less and adheres to a service contract);
may be composed of other services (service composition);
is a black-box to consumers of the service.
A software service is a service performed by a software program (or component).
57. Explain how service discovery works.
Service discovery means that, given a description of what the service is supposed
to do (the contract), a dynamic search is done for candidate services that are capable
of fulfilling that contract. One service, the service requestor, sends a lookup request for
another service to a service registry. If a suitable candidate service is found, its details are
returned to the service requestor, who can then be bound to that candidate service, the
service provider. Of course, the candidate service first has to register itself by publishing
information in the registry. The registry thus acts like a phone directory
58. What are the main characteristics of services?
Services can be discovered;
Services can be composed to form larger services;
Services adhere to a service contract;
Services are loosely coupled;
Services are stateless;
Services are autonomous;
Services hide their logic;
Services are reusable;
Services use open standards;
Services facilitate interoperability.
59. Can the same organization play the roles of service provider and service consumer at the
same time? If so, provide an example.

Nope.
60. Describe the SOSE development lifecycle.
Analysis: determine scope, gap analysis;
Architecture: decompose process, compose specific SOA;
Design: design services and their interfaces, design business process.
61. Explain the terms Quality of Service and Service Level Agreement in the context of service
orientation.
QoS is the set of the set of quality characteristics promised or required by a service. SLA is a
related term used in deployment context to describe certain levels of availability or
throughput.
62. What is a service contract?
A service contract is a description of what the service is supposed to do.
6. Checking for quality of software design models
63. Explain the notions of cohesion and coupling.
Cohesion may be viewed as the glue that keeps the component together. It is a
measure of the mutual affinity of the elements of a component. In general we will
wish to make the cohesion as strong as possible.
Coupling is a measure of the strength of the inter-component connections. A high
degree of coupling indicates a strong dependence between components. A high
degree of coupling between components means that we can only fully comprehend
this set of components as a whole and may result in ripple effects when a
component has to be changed, because such a change is likely to incur changes in
the dependent components as well. Loosely - coupled components, on the other
hand, are relatively independent and are easier to comprehend and adapt. Loose
coupling therefore is a desirable property of a design (and its subsequent
realization).
64. What is the essence of information hiding?
A service cannot retain information that is saved on behalf of a next invocation. A next
invocation may well be to another service with the same functionality, but from a different
provider.