Linköpings Universitet
IDA
SaS PELAB
Kristian Sandahl
2006-05-30
Written examination TDDC01 Software Engineering
theory
Date: Friday 2006-06-02
Time: 14:00-18:00
Allowed aids: One textbook of the Student’s choice. Hand-written notes in the book pages are
allowed. Dictionaries from English to another language without notes are allowed.
Explicitly forbidden aids: Electronic equipment, separate sheets of papers even if they are glued
in the book.
Writing: Please write or print clearly. We cannot give credit for unreadable solutions. You may
write solutions in English or Swedish. Problems should be solved on separate sheets of A4 paper.
Write only on one side of the paper and label all papers with name and personal number. When
grading the solutions we will split on problems, so if we find more than one problem on the paper
grading will be delayed.
Results: The graded exams are shown and handed out Wednesday August 16th between 11:0013:00 in conference room Donald Knuth, B-house, entrance 29, 1st floor, corridor B.
Questions: Examiner Kristian Sandahl will visit you about an hour after the start of the exam. He
can be reached at 013-28 19 57 or 0706-68 19 57 during the examination.
Solve as many as possible of the problems 1-10. They probably require only a few lines solution.
Each of the problems can give you 2 (two) credits.
Solve no more than two of the problems 11-15. They require a thorough solution of a few pages
each. Each of the problems can give you 10 (ten) credits.
Grading:
Credits
40
34-40
31-33
28-30
24-27
20-23
<20
Good luck!
Grade
Max
5
4
4
3
3
No pass
ECTS
Max
A
B
C
D
E
F
Problems:
Solve as many as possible of problems 1-10. Each problem gives a maximum of 2 credits.
The solutions should be focused and short.
1. Write down four quality factors that are especially important for critical systems.
For each of the factors, write down a short motivation of why they are important.
2. Write down two reasons of why a software system that is used in the real world
must be continuously updated or become progressively less useful.
3. Suppose you have the following activities in a project:
NUMBER
NAME
1
Requirement
analysis
Staffing
Writing project
plan
Writing
requirements
specification
Planning 1st 3
releases
Design release #1
2
3
4
5
6
START
DATE
2006-06-01
END
DATE
2006-06-30
PERSON
HOURS
320
PREREQUISITE
ACTIVITY
-
2006-06-10
2006-06-20
2006-07-15
2006-07-31
40
400
1, 2
2006-06-30
2006-08-15
400
1
2006-08-15
2006-08-20
30
3, 4
2006-08-20
2006-09-10
720
5
Draw two different types visualisation diagrams for these activities. Write down a
benefit for each of the two types.
4. Write down at least two functional user requirements and two non-functional
requirements in natural language for an unattended petrol station. The system
includes a credit card reader. The customer swipes the card through the reader and
then specifies the amount of fuel needed. The fuel is delivered and the customer’s
credit card account debited.
5. Your customer sent you this mail of the routines of buying raw material:
First, we calculate the needs from the Production Planning System
and check our own stock. The difference between the need and the
stock is sent to the Procurement System that creates a Bid Offer.
The Bid Offer is sent to known vendors via e-mail and is
advertised via our web-service. Known vendors send their bids
automatically to our web-service, and new vendors have to receive
a communication protocol definition object and a bid account
before their web-services can place a bid on our web-service.
After an open auction, the orders are put to lowest prices. If
not enough quantity can be bought, we place an order for the rest
from a known, but expensive, Provider outside the bidding
process.
Draw a UML sequence diagram showing the dynamic behaviour of the system.
6. Write down definitions and examples of four different metrics that can be used to
measure size and/or complexity of a class in an object-oriented programming
language.
7. Give an example of a metaphor that can be used in designing a Graphical User
Interface for a system of your own choice. Draw a rough sketch and describe the
system. Write down a benefit for the developers from using the metaphor.
8. Write down four prerequisites that must be met if a prototyping development
method can be considered.
9. Write down definitions of the test-terms: Oracle, Stub, Stress test, Coverage.
10. Write down a flow-chart or non-recursive pseudo code of any array sorting
algorithm. Write down test-cases that ensure branch coverage.
Solve no more than two of the problems 11-15. Each problem gives a maximum of 10
credits. Try to formulate with your own wording. The solutions should be thorough and
complete.
11. For the Observer design pattern below, write down thorough explanations of the
meaning of all classes, attributes, methods and associations. You shall use an
example to make your points easier to read.
Subject
attach(Observer)
detach(Observer)
notify()
Observer
* update()
ConcreteSubject
ConcreteObserver
subjectState
observerState
getState()
setState()
update()
12. Select five life-cycle models or process models from your book. For each of the
models, write down the answers to the following questions:
a. What benefits does the model offer a group of 6-8 students developing
their first piece of software from customer requirements?
b. What benefits does the model offer a professional group of 20-100
programmers developing most of the software themselves?
c. What activities in the model will change if a professional group of 20-100
programmers group reuses components and only code about 5% of the
software themselves?
d. Select an activity that a professional group of 20-100 programmers can
outsource to someone else. Why did you choose this activity?
13. There are about five major architectural styles normally described in text books.
Their benefits are often only described in terms of maintainability, that is, the ease
of which people understand the software and the effort it takes to make a change
in the software. Many practitioners and theoreticians claim that the architectural
design has strong implications for the resulting system’s quality factors. Now,
write down 5 tuples, each made up of an architectural style and a quality factor,
other than maintainability. For each tuple you should write down an example
that clearly explains how design decisions affect the quality factor. A design
decision can either be the choice of a particular architectural style or a decision of
how to instantiate part of the style, for example, to decide about the number of
layers in a layered architecture. You will get 0-2 credits per tuple depending on
the quality of your example. You can only get credits for maximally 2 negative
tuples, that is, architectural design decisions that make the software worse from
the view of the particular quality factor.
14. Imagine a theatre ticket booking system. The customer can buy tickets on-line or
at the ticket office. The officer can sell tickets and schedule the performances.
Draw UML(* views of the systems:
a. At least 5 use-cases
b. At least 5 classes
c. A state-diagram with at least 5 states
d. A sequence diagram with at least 5 messages
e. An activity diagram with at least one synchronization bar
f. A deployment diagram with at least two nodes
(*
If you are not certain about wether some parts of your diagram is standard
UML, please provide explanations of the notions you introduce.
15. There are many techniques and methods for accomplishing safety-critical systems
such as:
a. Using formal specifications.
b. Hiring independent experts for inspections.
c. Using statistical usage testing.
d. Using experience-derived checklist.
e. Making hazard-analyses.
f. Developing a company culture of safety.
g. Using statistical process control of your development process.
h. Deploying the Cleanroom process model.
Select five of these (or suggest your own). For each of the methods write down:
1. A thorough description of the method.
2. A description of the costs (items, not dollars) of initiating and running the
method
3. The contributions to safety that are likely to follow from the method.