Øving 2
78038 Programvarekvalitet
Vår 2000
Gruppe 2B
Håkon Groven Halvorsen
Kjartan Rydland
Section 1
i)
Vi deltok på introduksjonsforelesning til øvingen der teknikkene ble presentert. Vi fikk
tilgang til foilene fra denne forelesningen, og så gjennom disse. En del var likevel uklart,
og vi spurte øvingsansvarlige en del spursmål rundt dette.
Det som var uklart var en del begreper som ble brukt som vi ikke helt visste om vi hadde
den riktige forståelsen av. Dette var nok litt fordi vi ikke har noen bakgrunn i å lese/bruke
UML. Vi forsøkte å lese forelesningsnotatene for å forsøke og forstå, og satset på at
forståelsen kom litt etter hvert når vi holdt på.
Rollen til spørsmålene i hver del var også litt uklart for oss, hva skulle besvares for å
være en output til en annen del og hva skulle besvares for å hjelpe å avdekke feil? Her
fikk vi litt hjelp fra øvingsansvarlige.
Resten av tiden til forberedelser gikk med til å lese gjennom ’reguirements document’.
ii)
We think that the OORTs were useful for their task. It is quite obvious that our (lack of)
background/knowledge about the modelling language used in the requirements document
of the PGCS case put strict limitations on our work.
iii)
We don’t have any hints about improving the OORTs since our level of
competence/insight is to low to see its backdraws/benefits.
Section 2
Fag 78038 Programvarekvalitet og prosessforbedring
IDI, NTNU, vår 2000
Øving 2: Inspeksjon
Defect list
OORT-2: State Diagram x Class Description Discrepancy Report
One record for each defect:
Object/Class Name:
Granularity: (state, event, behavior, condition)
Concept Name:
Type of defect: (inconsistency, extraneous, miscellaneous)
Description:
Monthly_ticket
Condition
?
Inconsistency
In the state diagram, getting from
state valid to expired is through
the condition elapsed days = 30. In
the class description, the same
transition is trough elapsed
days>30.
Object/Class Name:
Granularity: (state, event, behavior, condition)
Concept Name:
Type of defect: (inconsistency, extraneous, miscellaneous)
Description:
Monthly_ticket
Condition
?
Inconsistency
In the state diagram, getting from
state expired and back to expired
is through the condition elapsed
days > 30. In the class description,
the same transition is trough any.
Object/Class Name:
Granularity: (state, event, behavior, condition)
Concept Name:
Type of defect: (inconsistency, extraneous, miscellaneous)
Description:
Non-reserved_ticket
Condition
?
Inconsistency
In the state diagram, getting from
state valid and back to valid is
through the condition time elapsed
<= 15. In the class description, the
same transition is trough time
elapsed < 15.
Object/Class Name:
Granularity: (state, event, behavior, condition)
Non-reserved_ticket
Condition
Concept Name:
Type of defect: (inconsistency, extraneous, miscellaneous)
Description:
?
Inconsistency
In the state diagram, getting from
state valid to expired is through
the condition time elapsed > 15. In
the class description, the same
transition is trough time elapsed
>= 15.
OORT-3: State Diagram x Sequence Diagram Discrepancy
Report
Utfører: Håkon Halvorsen
Class Name:
Type of defect:
Description:
Driver
Missing
Defined in the seq diagram, but not in the state diagram
Class Name:
Type of defect:
Description:
Card Reader
Missing
Defined in the seq diagram, but not in the state diagram
Class Name:
Type of defect:
Description:
Ticket
Missing
Defined in the seq diagram, but not in the state diagram
Class Name:
Type of defect:
Description:
Exit Gate
Missing
Defined in the seq diagram, but not in the state diagram
Class Name:
Type of defect:
Description:
Monthly Ticket Driver
Missing
Defined in the seq diagram, but not in the state diagram
Class Name:
Type of defect:
Description:
gate
Missing
Defined in the seq diagram, but not in the state diagram
Class Name:
Type of defect:
Description:
Ticket Dispencer
Missing
Defined in the seq diagram, but not in the state diagram
Class Name:
Type of defect:
Description:
Entry Gate
Missing
Defined in the seq diagram, but not in the state diagram
Class Name:
Type of defect:
Description:
Control Unit
Missing
Defined in the seq diagram, but not in the state diagram
Class Name:
Type of defect:
Description:
Non-reserved_ticket
Missing
“Driver repays” defined in the state diagram, but not in the seq diagram
Class Name:
Type of defect:
Description:
Parking Garage
Missing
“Only 1 space available and monthly ticket is purchased” defined in the
state diagram, but not in the seq diagram
Class Name:
Type of defect:
Parking Garage
Missing
Description:
“Monthly ticket expires” defined in the state diagram, but not in the seq
diagram
Class Name:
Type of defect:
Description:
Parking Garage
Missing
“Monthly ticket expires” defined in the state diagram, but not in the seq
diagram
OORT-6: Sequence Diagram x Use Case Diagram Discrepancy
Report
Utfører: Kjartan Rydland
Which classes is involved?
Concept name:
Granularity:
Type of defect:
Description:
Parking Garage
Lot
Class
Omission
“Lot” is missing in SqD. Should be parking garage?
Which classes is involved?
Concept name:
Granularity:
Type of defect:
Description:
Control Unit
Cashier
Objec
Omission
“Cashier” is missing in SqD. Included in Control Unit?
Which classes is involved?
Concept name:
Granularity:
Type of defect:
Description:
Control Unit
System
Object
Omission
“System” is missing in SqD. Included in Control Unit?
Which classes is involved? Control Unit
Concept name:
Control Unit
Granularity:
Class
Type of defect:
Incorrect fact
Description:
For purcase monthly ticket: I use cases står det at “cashier
notifies system of ticket purcase” mens SqD opererer med “Control unit”
OORT-7
Utfører: Kjartan Rydland
Q73c
Document: State Diagram
Class Name:
Non-reserved_ticket
Concept Name:
Leave lot
Granularity:
Event
Type of Defect:
Extraneous
Description:
The event ”leave lot” may cause the transition from state 2 to state
1.
Q74.b:
Document: State Diagram
Class Name:
Non-reserved_ticket
Concept Name:
Driver_repays
Granularity:
Condition
Type of Defect:
Extraneous
Description:
The transition ”Nonreserved leaves or monthly ticket expires” not
found in the RD/Use cases.
Section 3
Fag 78038 Programvarekvalitet og prosessforbedring
IDI, NTNU, vår 2000
Øving 2: Inspeksjon
Observation Notes Templates for Object-Oriented Reading
Techniques (OORTs), filled in by Process Observer
Intro
Det er her nevnt de problemer og uklarheter executor møtte på under inspeksjonen.
Dette er presentert hovedsaklig i spørsmålsform der spørsmålet kom opp. Der det ikke
er gitt noen komentarer gikk inspeksjonen greit uten vesentlige uklarheter og problemer.
OORT-2: State Diagram x Class Description
Det ble på denne delen brukt 80 minutt.
Det var her litt uklart om en skulle gå ut fra at statechart’ene var korrekt og se på om
classdescriptions var riktige iht. Statechart’ene. Executor gikk ut fra dette.
Det var også litt uklart hvorfor en trengte å fylle inn alle feltene i Template for defect list,
er det ikke tilstrekkelig med bare den siste delen, under ’Document: Class Description’.
Uklarhet: Concept name: hva er det?
Step R2.1: Read state diagram to understand
possible states and their transition.
–Q21.a:
Identify the actual class from the state diagram. Missing? [omission?]
–Q21.b:
Underline the name of each object state (by blue pen).
–Q21.c:
Underline the transition actions/conditions (by green pen).
Disse tre var greie å forstå og utføre.
–Q21.d:
Can you understand the object's behavior from Q21.b-c above? [ambiguity?]
Hvordan vurderer en om en forstår oppførselen?
Step 2.2: Identify the associated class, and its attributes and
behavior.
Hvor detaljert skal en gå inn I class descriptions, hvordan er forholdet mellom
beskrivelsen av interface/operations etc. og matrisa på slutten, hva skal en se på?
–Q22.a:
In the CDe, identify the class being modeled by this state diagram.
Missing? [omission?]
Hva er forskjellen på Q21.a og Q22.a?
–Q22.b: Find
out how a blue state is represented, i.e. has the class captured
state in a unique way?
an explicit attribute.
implicit attribute (merely via control flow).
combination of attributes.
subtyping of the actual object (consult the class hierarchy).
the result. [inconsistency? or ambiguity?]
–Q22.c:
each modeled
E.g. by
E.g. by an
E.g. by a
E.g. by
Report
Are all green transition actions/conditions covered by class behavior?
If not: error. [inconsistency?]
Uklarhet: Hva menes med ‘covered by class behaviour’?
–Q22.d:
Are green transition conditions using object data, that are defined as class
attributes with matching names?
If not: error. [inconsistency?]
Step R2.3: Compare class diagram to state
diagram.
–Q23.a: From
your domain knowledge, are all relevant states defined in the StD?
[incorrect fact?]
–Q23.b: For each
unmarked state, assess if it is appropriate and essential:
[incorrect fact? or extraneous?]
–Q23.c: For each
[inconsistency?]
OK.
unmarked transition action/condition: here is missing information.
OORT-3 Sequence Diagram x State Diagram
På denne delen ble det brukt 90 min.
Step R3.1: Read the state diagram to understand the possible
object states, their transitions and corresponding actions.
Man skal her bare se på statecharts, da blir det vel det samme som i introen til OORT-2?
Ellers OK her.
–Q31.a:
Determine which class is being modeled. Missing? [omission?]
–Q31.b:
Trace all transitions from the start state to the end state, and mark
corresponding actions with a unique name (A1, A2 etc.) with a green pen.
–Q31.c:
In general, do these transitions/actions and states make sense and are they
understandable for such an object? [ambiguity?]
Step R3.2: Read the sequence diagrams to
understand how the transition actions are achieved
by messages sent to/from the relevant object.
–Q32.a: Pick
the relevant subset of SqDs concerning this state diagram (StD)
Is there a problem to identify these? [omission? or extraneous?]
For each relevant sequence diagram (SqD) do below points Q32.b-e:
Litt usikker på hvilke SqD som er relevant, brukte en del til på det, OK til slutt.
Litt vanskelig å kategorisere feil.
–Q32.b:
Read the sequence diagram to identify the associated system service and its
messages.
–Q32.c:
Identify the object states in the StD, being semantically related to the
system service.
actual
–Q32.d:
Map message arrows (one or many) in the SqD to state transitions in the StD.
Are there “enough” messages to accomplish a given transition? [omission?]
Mark related SqD-messages and StD-transitions with a green star.
–Q32.e:
Look for constraints and conditions on the above SqD-messages.
Check
if the same constraint/condition information stands in both diagrams. [inconsistency?]
Such SqD-information may be correspondingly expressed in the StD by:
1) State information
(e.g. t>0),
2) Transition information (what occurs when t>0?),
3) Nothing
(not relevant for StD).
Uklarhet: Hva menes med constraints and conditions?
Step R3.3: Review the marked-up diagrams to make
all transition actions are accounted for.
sure that
–Q33.a:
Look for unlabeled transaction actions in the StD, i.e. those not
implemented by available messages in the SqD (cf. Q32.d).
Report these. [inconsistency?]
–Q33.b:
Are the event order the same in the StD and SqD, i.e. check if labeled
messages/transitions in the SqD appear in logical order? [inconsistency?]
E.g. that action Ax on a later transition in the StD actually occurs after an action Ay
on an
earlier transition.
Problemer med å lese SqD, vi har så å si ingen erfaring med UML, og spesielt ikke med
SqD, så dette blir litt halvvegs.
OORT-6: Sequence Diagram x Use Case Diagram
På denne delen ble det brukt 65.min.
Step R6.1: Identity the main functionality of a use case and ts
important system concepts.
Hva er system services?
–Q61.a: Find the
unique nouns/concepts in the UC.
Underline and number consecutively with a blue pen (used in Q61.d).
Uklarhet: hva er consepts?
–Q61.b: For each
noun, find verbs/actions "to or by" that noun.
Underline and number in assumed performance order with a green pen.
–Q61.c:
Mark constraints/conditions in double-green (part of service marking).
Uklarhet: Hva menes med constraints/conditins?
–Q61.d:
Also find the information or data to be sent/received in order to perform a certain
action.
Label the data in
yellow as "Dx,y", where x,y are the nouns involved.
Step R6.2: Identify and inspect the related
sequence diagrams, to identify if the corresponding
functionality is described accurately and whether behaviors and
data are represented in the right order.
Executor valgte å se på ’lot’ som det samme som ’parking garage’.
–Q62.a: For each
SqD, underline in blue the system objects, and with the same noun
number (from Q61.a) as in the UC.
–Q62.b:
Identify the services described in the SqD.
I.e. look at the horizontal message arrows between objects, and possibly cluster
several arrows into one service.
Underline the identified services in green, and number them in occurrence order (top-tobottom) in the SqD.
–Q62.c:
Identify information/data exchanged between two system classes (x,y).
Label the data in yellow as "Dx,y", as in R6.1.
Step R6.3: Compare the marked-up Use Case / Sequence
Diagrams to determine whether they
represent the same domain concepts.
–Q63.a: For each
blue-marked noun in the UC, search for a similar one in the SqD.
Mark by blue star (“*”) in the UC if found.
For unstarrred nouns in the UC, check also if they possibly are attributes in some class.
The remaining, unstarred nouns from the UC may represent defects, as they are missing in
the design (SqD). [omission?]
–Q63.b:
Similarly, for each unmarked noun in the SqD, it may belong to some designinternal or worse: an unused concept. [extraneous?]
–Q63.c: For each blue-marked
service in the SqD, look for the corresponding done in the
UC.
E.g. Are SqD
classes/objects exchanging messages in the same order as in the UC? If not, this may be a
defect.
E.g. Are
message parameters on the SqD correctly described in the UC, e.g. right data between right
Dx,y etc.?
E.g. Is it
possible to “understand” the expected functionality,
for instance from data being sent/received, by just reading the SqD?
Report any problem in all this. [inconsistency? or ambiguity?]
Litt uklart hva som det blir spurt etter her, hva menes med ‘possible to understand the
expected functionality’?
Igjen: vi har ikke noen bakgrunn i å lese Sqd.
–Q63.d:
Are double-green-marked constraints/conditions from the UC being observed by the
SqD? [incorrect fact?]
OORT-7: State Diagram x (Rqmt Descr / Use Case)
På denne delen ble det brukt 75 min.
Step R7.1: Read the state diagram to basically understand what
the object it is modeling
(nothing more here).
Litt problemer med å forstå StD’ene ang start og end state, dette gjorde at problematikk
rundt dette dette kanskje ikke ble inspisert som tenkt i det påfølgende.
Step R7.2: Read the functional requirements to
determine the possible states of the object,
which states are adjacent to each other, and which
events/actions cause the state changes.
–Q72.a: Put away
the StD and erase any previous stars (“*”) in the RD.
Read through the RD and mark up lightly – with a star (“*”) by a pencil – the
places where the actual StD-object/concept is used.
–Q72.b:
Locate all corresponding places in the RD for all different states of this object,
mark these places with a blue pen and number them from 1..N.
–Q72.c:
Identify which of the numbered states being the Initial state ("I"), and similarly
with the end state ("E").
Problemer med å finne initial state og end state i functional requirements.
–Q72.d:
Make a N*N Adjacency Matrix (AM) on a separate sheet of paper.
Try to identify possible ij-state transitions here, i.e. if state i can lead to state j.
Put a check mark (“v”) in these AM-ij entries.
Step R7.3: Read the use cases and determine the events that
cause state changes.
–Q73.a:
Read through the use cases and find the ones where the object
participates.
–Q73.b: For each marked AM-ij
entry (i.e. having a transition), document precisely the
associated event and/or constraint someplace on the AM paper sheet.
–Q73.b: For the
blank entries, see if there still might be events that may cause the
transition. If not, write a “X” in that entry.
Step R7.4: Read the state diagrams to determine if the
described states are consistent with the requirements, and if
the transitions are consistent with the requirements and use
cases.
Det ble nok litt halvvegs her også på grunn av problemer med forståelse av
SqD
–Q74.a: For each
numbered state in the RD, find the corresponding state in the StD
and mark it with a blue pen and corresponding number.
Note: state names may be different in the RD and the StD, and
overlapping names may not represent identical states.
E.g. Were all states in the RD found in the StD? [omission?]
Or maybe some RD states were combined into one StD state,
but this was not a sensible combination? [incorrect fact?]
E.g. Inversely, were there extra states in the StD? [extraneous?]
Or maybe a RD state was split into more than one StD state,
but again this was not a sensible combination? [incorrect fact?]
–Q74.b:
Check transition events and actions in the AM-matrix/sheet:
E.g. Do all events in the AM appear on the StD? [omission?]
E.g. Do all events in the StD appear on the AM? [extraneous?]
–Q74.c:
Check transition constraints in the AM-matrix/sheet:
E.g. Do all constraints in the AM appear on the StD? [omission?]
E.g. Do all constraints in the StD appear on the AM? [extraneous?]
Experience Questionnaire
(for OO Reading techniques)
Name ___Kjartan Rydland_______________________________________________
General Background
Please estimate your English-language background:
__ I am a native speaker.
X__ English is my second language. [Please complete both of the following.]
My reading comprehension skills are:
__ could be better
__ moderate
X__ high
__ very high
My listening and speaking skills are:
__ could be better
__ moderate
X__ high
__ very high
What is your previous experience with software development in practice? (Check
the bottom-most item that applies.)
__ I have never developed software.
__ I have developed software on my own.
X__ I have developed software as a part of a team, as part of a course.
__ I have developed software as a part of a team, in industry.
Please explain your answer. Include the number of semesters or number of years
of relevant experience. (E.g. “I worked for 10 years as a programmer in
industry.”)
I have studied computer science for 7,5 semesters.
Software Development Experience
Please rate your experience in this section with respect to the following 5-point scale:
1 = none
2 = studied in class or from book
3 = practiced in a class project
4 = used on one project in industry
5 = used on multiple projects in industry
Experience with Requirements





Experience writing requirements
Experience writing use cases
Experience reviewing requirements
Experience reviewing use cases
Experience changing requirements for maintenance
1
X1
X1
X1
X1
X2
2
2
2
2
3
3
3
3
3
4
4
4
4
4
5
5
5
5
5
Experience in Design






Experience in design of systems
1 2
Experience in design of systems from requirements/use cases
4 5
Experience with creating Object-Oriented (OO) designs 1 2
Experience with reading OO designs
1 X2
Experience with the Unified Modeling Language (UML) X1 2
Experience changing designs for maintenance
X1 2
X3 4
1 2
5
X3
X3
3
3
3
4
4
4
4
5
5
5
5
X3 4
X3 4
5
5
X1 2
3
4
5
1 2
X1 2
X1 2
X3 4
3 4
3 4
5
5
5
1 2 X3 4
1 X2 3 4
X1 2 3 4
5
5
5
Experience in Coding




Experience in coding, based on requirements/use cases
Experience in coding, based on design
Experience in coding, based on OO design
Experience in maintenance of code
1
1
2
2
Experience in Testing



Experience in testing software
Experience in testing, based on requirements/use cases
Experience with equivalence-partition testing
Other Experience



Experience with software project management?
Experience with User Interface (UI) design?
Experience with software inspections?
Experience in Problem Domains
We will use answers in this section to understand how familiar you are with
various systems we may use as examples or for assignments during the class.
Please rate your experience in this section with respect to the following 3-point scale:
1 = I’m really unfamiliar with the concept. I’ve never done it.
3 = I’ve done this a few times, but I’m no expert.
5 = I’m very familiar with this area. I would be very comfortable doing this.
How much do you know about…
 Applying for a loan?
 Applying for a mortgage?
 Using a parking garage?
 Using an ATM?
 Renting movies from a video rental store?
X1
1
1
1
1
3
X3
X3
X3
3
5
5
5
5
X5
Experience Questionnaire
(for OO Reading techniques)
Name _Håkon Groven Halvorsen_________________________________________________
General Background
Please estimate your English-language background:
__ I am a native speaker.
X English is my second language. [Please complete both of the following.]
My reading comprehension skills are:
__ could be better
__ moderate
X high
__ very high
My listening and speaking skills are:
__ could be better
__ moderate
X high
__ very high
What is your previous experience with software development in practice? (Check
the bottom-most item that applies.)
__ I have never developed software.
__ I have developed software on my own.
X I have developed software as a part of a team, as part of a course.
__ I have developed software as a part of a team, in industry.
Please explain your answer. Include the number of semesters or number of years
of relevant experience. (E.g. “I worked for 10 years as a programmer in
industry.”)
Software Development Experience
Please rate your experience in this section with respect to the following 5-point scale:
1 = none
2 = studied in class or from book
3 = practiced in a class project
4 = used on one project in industry
5 = used on multiple projects in industry
Experience with Requirements





Experience writing requirements
Experience writing use cases
Experience reviewing requirements
Experience reviewing use cases
Experience changing requirements for maintenance
1
1
1
1
1
2
2
2
2
2
3
3
3
3
3
4
4
4
4
4
5
5
5
5
5
Experience in design of systems
1 2
Experience in design of systems from requirements/use cases
4 5
Experience with creating Object-Oriented (OO) designs 1 2
Experience with reading OO designs
1 2
Experience with the Unified Modeling Language (UML) 1 2
Experience changing designs for maintenance
1 2
3
1
4
2
5
3
3
3
3
3
4
4
4
4
5
5
5
5
Experience in Design






Experience in Coding




Experience in coding, based on requirements/use cases
Experience in coding, based on design
Experience in coding, based on OO design
Experience in maintenance of code
1
1
1
1
2
2
2
2
3
3
3
3
4
4
4
4
5
5
5
5
1
1
1
2
2
2
3
3
3
4
4
4
5
5
5
1
1
1
2
2
2
3
3
3
4
4
4
5
5
5
Experience in Testing



Experience in testing software
Experience in testing, based on requirements/use cases
Experience with equivalence-partition testing
Other Experience



Experience with software project management?
Experience with User Interface (UI) design?
Experience with software inspections?
Experience in Problem Domains
We will use answers in this section to understand how familiar you are with
various systems we may use as examples or for assignments during the class.
Please rate your experience in this section with respect to the following 3-point scale:
1 = I’m really unfamiliar with the concept. I’ve never done it.
3 = I’ve done this a few times, but I’m no expert.
5 = I’m very familiar with this area. I would be very comfortable doing this.
How much do you know about…
 Applying for a loan?
 Applying for a mortgage?
 Using a parking garage?
 Using an ATM?
 Renting movies from a video rental store?
1
1
1
1
1
3
3
3
3
3
5
5
5
5
5