Garantie de satisfaction à 100% Disponible immédiatement après paiement En ligne et en PDF Tu n'es attaché à rien
logo-home
Recherché précédemment par vous
Recherché précédemment par vous
logo
Software Specification (2IX20) Summary Q3 2021 $4.47
Ajouter au panier
Accédez rapidement à
Aperçu
  2.  
  3. Technische Universiteit Eindhoven (TUE)
  4.  
  5. Software Specification (2IX20)

Resume

Software Specification (2IX20) Summary Q3 2021

1 vérifier
 7 fois vendu
  • Cours
  • Software Specification (2IX20)
  • Établissement
  • Technische Universiteit Eindhoven (TUE)

EN: Software Specifications (2IX20) is a course taught at Eindhoven University of Technology. It is a mandatory course for Bachelor Computer Science and Engineering students. The course is given in the third quartile of the second year. Software Specifications discusses requirements, all kinds of d...

[Montrer plus]
Dernier document publié: 3 année de cela

Aperçu 4 sur 22  pages

Infos sur le Document

  • 1 avril 2021
  • 2 avril 2021
  • 22
  • 2020/2021
  • Resume

Sujets

  • software
  • specification
  • software specificiations
  • specifications
  • 2ix20
  • computer science
  • requirements
  • informal
  • formal
  • spin
  • use case diagram
  • object diagram
  • class diagr
  • tue
  • computer science and engineering

École, étude et sujet

  • Technische Universiteit Eindhoven (TUE)
  • Computer Science And Engineering
  • Software Specification (2IX20)
Tous les documents sur ce sujet (1)

1  vérifier

review-writer-avatar

Par: krisik03 • 4 mois de cela

Vendeur

avatar-seller
IsabelRutten

Avis reçus

Aperçu du contenu

Software Specifications (2IX20) Summary Q3 2021
Contents
Week 1 – Tuesday: Introduction and Requirements ..................................................................................... 2
Week 1 – Thursday: Use case diagrams and use cases............................................................................... 2
Week 2 – Tuesday: Object and class diagrams ............................................................................................ 4
Week 2 – Thursday: State machine diagrams .............................................................................................. 6
Week 3 – Tuesday: Sequence diagrams ...................................................................................................... 8
Week 3 – Thursday: Activity diagrams ........................................................................................................ 11
Week 4 – Tuesday: LTS and KS................................................................................................................. 13
Week 4 – Thursday: LTL ............................................................................................................................ 15
Week 5 – Tuesday: SPIN ........................................................................................................................... 16
Week 5 – Thursday: State machine diagram semantics ............................................................................. 19
Week 6 – Tuesday: MBT ............................................................................................................................ 21




1
Software Specifications (2IX20) Summary Q3 2021 by Isabel Rutten

,Week 1 – Tuesday: Introduction and Requirements
This course helps us think about design, software quality, certification requirements and bugs.
We will cover three topics: informal specification, formal specification and model-based testing.
We use the V-model, which on the left hand side creates the requirements with the corresponding code
and on the right hand side verifies them. Validation refers to assessing the quality of one level while
verification refers to the quality between two different levels.




A requirement is a statement expressing a need (capability) and its associated constraints and conditions.
This is written in natural structural language, which is semi-formal. The goal of a requirement specification
is to enable an agreed understanding between stakeholders of the objectives of the system. Requirements
engineering is getting from user needs to the requirement specification/document, which is a collection of
requirements. For each requirement, we give identification, dependencies, source(s), rationale and
priorities (MoSCoW method). Steps:
1. Requirements elicitation: techniques include interview, brainstorm, analyze, prototype, etc.
2. Requirements specification: Steps: 2a) Identify actors and their goals; 2b) Specify inputs, outputs of
the system; 2c) Write requirements. (if using informal text: 2d) go through text to find more requirements).
3. Requirements verification and validation: ensures requirements are consistent, complete and feasible
4. Requirements management: to analyze, document, track, prioritize and keep track of the requirements
Good requirements are unambiguous, consistent/non-contradictory, verifiable, appropriate, necessary,
complete, singular, feasible, correct and conforming.
Semi-formal requirements should conform to ISO29148 and have the following structure:
[Condition1][Subject2][Action3][Object4][Constraint of Action5] (one can leave out the condition)
1: when is the requirement applicable. 2: actor. 3: action or verb of requirement e.g. “shall send”.
4: object of the action. 5: restriction on the action e.g. time limit.
Example: When signal x is received [Condition], the system [Subject] shall set [Action] signal x received bit
[Object] within 2 seconds [Constraint of Action].
To be avoided: - shall be able to; - negative statements; - passive voice; - superlatives (best)
- subjective language (easy); - vague pronouns (its); - ambiguous adverbs and adjectives (minimal);
- open-ended, non-verifiable terms; - comparative phrases; - loopholes (if possible).

Week 1 – Thursday: Use case diagrams and use cases
A use case diagram expresses expectations of customers/stakeholders, is used during entire analysis and
design process and can be used to answer what is being described (system), who interacts with the system
(actors) and what the actors can do (use cases). Use cases are more structured and require less
documents than requirements.




2
Software Specifications (2IX20) Summary Q3 2021 by Isabel Rutten

, In the following table, one can find the different components of the use case diagram.
Notation Name Description
System Boundaries between the system and the users of the system.


Use Case Unit of functionality of the system. Describes functionality, provides
benefit for 1/ more actors, derived from collected
customer/stakeholder wishes, set of all use cases describes
functionality system shall provide (documents the functionality that a
system offers). Use cases contain: name, short description,
precondition, postcondition, error situations, system state on the
occurrence of an error, actors that communicate with the use case,
trigger, standard process, alternative processes.
Actor Role of the users of the system. Interact with the system by using
use cases or by being used by use cases, represent roles that users
adopt, are not part of the system. User data is usually administered
within system, data is modeled within system as objects and classes.
There are different types of actors: human/non-human,
primary/secondary (main benefit/no direct benefit), active/passive
(initiates execution/provide functionality for execution)
Include A includes B means required use of use case B by use case A. A is
relationship the base use case and B is the included use case (which may be
executed on its own).
Extend B extends A means optional use of use case B by use case A. A is
relationship the base use case and B is the extending use case. Both may also
be executed independently of each other. A decides if B is executed.
Extension points define at which point the behavior is integrated and
is written directly within the use case; multiple extension points can
be specified. Conditions define under which circumstances the
behavior is integrated.
Generali- Inheritance relationship between actors or use cases. (Base) Use
zation case A generalizes (sub) use case B. B inherits behavior of A and
may extend/overwrite it. B inherits all relationships from A. B adopts
basic functionality of A but decides what part of A is executed or
changed. A may be labeled {abstract} (then A cannot be executed
directly and only B is executable).
Association Relationship between use cases and actors. Solid line. An
association is always binary. Multiplicities may be specified
(min..max).
Best practices identifying actors: answer questions like who uses the main use cases? Who needs
support? Who is responsible? What are external devices? Who is interested in results?
Best practices identifying use cases: answer questions like what are the main tasks that an actor must
perform? Does an actor what to query/modify information? Does an actor want to inform about changes in
other systems? Should an actor be informed about unexpected events?
Remember that for this course we follow the UML standard. Thus for the extend and include relation:




Typical errors to avoid: use case diagrams do not model processes/workflows; actors are not part of the
system and thus should be positioned outside the system boundaries; one can use abstract and
generalization to achieve the either relation for actors; many small uses cases that have the same objective
may be grouped to form one use case; the various steps are part of the uses cases and not separate use
cases themselves (no functional decomposition).
3
Software Specifications (2IX20) Summary Q3 2021 by Isabel Rutten

, Week 2 – Tuesday: Object and class diagrams
Structure is the aggregate of elements of an entity in their relationships to each other. Structural design
focusses on how to meet the requirements (design, not implementation). We require traceability (ensure
that we address all requirements). A structure diagram is a diagram that identifies modules, activities, or
other entities in a system or computer program and shows how larger or more general entities break down
into smaller, more specific entities.
An object diagram is a structure diagram that is a snapshot of objects of system and their relationships
(links) at a specific moment in time. The following table shows different components of the object diagram.

Notation Name Description
Object Instance of a class. Individual of a system.




Link Relationship between objects.


Individuals of a system (objects) often have identical characteristics and behavior: a class is a construction
plan for a set of similar objects of a system. Thus we can go from objects to classes. Attributes are the
structural characteristics of a class (different for each object) and operations are the behavior of a class
(identical for all objects). Then we have the class diagram:
Notation Name Description
Class Description of the structure and behavior of a set of objects.
Attribute syntax:



Visibility: + public, - private, # protected, ~ package. Type: e.g. String
Multiplicity: [min..max].Property: readOnly, (non-)unique, (un)ordered
Different levels of detail: Operation syntax:



Parameter: in (input), out (output), inout (combined). Type: of return.
Instance variable: instance attribute (attributes defined on instance)
Class variable: static class attribute, defined once per class
Class operation: static operation, can be used if no instance of the
corresponding class was created. Class var/op are underlined.
Abstract Class that cannot be instantiated. This can be used in combination
class with generalization. Then it is used to highlight common
or characteristics of subclasses and used to ensure there are no direct
instances of the superclass. Only non-abstract subclasses can be
instantiated. Use keyword {abstract} or italic font.
Association Relationship between classes: navigability unspecified, navigable in
both directions, not navigable in one direction.
Most common is binary association.
Navigability: an object knows its partner objects and can therefore
access their visible attributes and operations (open arrow head).
Non-navigability (indicated by cross). Navigability undefined:
bidirectional navigability assumed.
Can have multiplicity (number of objects that may be associated
with exactly one object of the opposite side) and a role (describes
the way in which an object is involved in an association relationship).
4
Software Specifications (2IX20) Summary Q3 2021 by Isabel Rutten

Les avantages d'acheter des résumés chez Stuvia:

Qualité garantie par les avis des clients

Qualité garantie par les avis des clients

Les clients de Stuvia ont évalués plus de 700 000 résumés. C'est comme ça que vous savez que vous achetez les meilleurs documents.

L’achat facile et rapide

L’achat facile et rapide

Vous pouvez payer rapidement avec iDeal, carte de crédit ou Stuvia-crédit pour les résumés. Il n'y a pas d'adhésion nécessaire.

Focus sur l’essentiel

Focus sur l’essentiel

Vos camarades écrivent eux-mêmes les notes d’étude, c’est pourquoi les documents sont toujours fiables et à jour. Cela garantit que vous arrivez rapidement au coeur du matériel.

Foire aux questions

Qu'est-ce que j'obtiens en achetant ce document ?

Vous obtenez un PDF, disponible immédiatement après votre achat. Le document acheté est accessible à tout moment, n'importe où et indéfiniment via votre profil.

Garantie de remboursement : comment ça marche ?

Notre garantie de satisfaction garantit que vous trouverez toujours un document d'étude qui vous convient. Vous remplissez un formulaire et notre équipe du service client s'occupe du reste.

Auprès de qui est-ce que j'achète ce résumé ?

Stuvia est une place de marché. Alors, vous n'achetez donc pas ce document chez nous, mais auprès du vendeur IsabelRutten. Stuvia facilite les paiements au vendeur.

Est-ce que j'aurai un abonnement?

Non, vous n'achetez ce résumé que pour $4.47. Vous n'êtes lié à rien après votre achat.

Peut-on faire confiance à Stuvia ?

4.6 étoiles sur Google & Trustpilot (+1000 avis)

65040 résumés ont été vendus ces 30 derniers jours

Fondée en 2010, la référence pour acheter des résumés depuis déjà 15 ans

Commencez à vendre!

Récemment vu par vous

Resume ·

(0)

Summary Thinking Fast and Slow (Kahneman)

Examen ·

(1)

ATI MATERNAL NEWBORN PROCTORED 2023 GRADED A

Resume ·

(0)

godsdienst havo 2 samenvatting thema 3

Examen ·

(0)

NISHA APEA 3P EXAM 2023/2023 VERIFIED ANSWERS

Examen ·

(0)

EMT basic drug cards with verified solutions

Pack ·

(0)

Samenvatting Minor klinische voeding

Examen ·

(0)

LMPT test 4 Questions And Answers 2023

Examen ·

(0)

Scheikunde geleidbaarheid practicum H4

Resume ·

(0)

Samenvatting socialezekerheidsrecht begrepen

$4.47  7x  vendu
  • (1)
Ajouter au panier
Ajouté