Summary
Software Analysis Samenvatting HoGent
- Course
- Institution
Samenvatting van het vak Software Analysis, in het 1ste bachelor van het traject Toegepaste Informatica (TI)
[Show more]
2 reviews
By: maerten1 • 11 months ago
By: achilebatier • 11 months ago
Seller
Follow
TomDeBakker
Reviews received
Content preview
Software AnalysisTom De Bakker
23/12/2023
1
,Inhoudstafel
Software Analysis 4
Andere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Evaluatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Hoofdstuk 1: Inleiding 5
Hoofdstuk 2: Software-ontwikkelingsproces 6
2.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Hoe verloopt een project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1 Projectleider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.2 Analist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.3 Ontwerper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.4 Programmeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.5 Tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Methodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.1 Waterval methode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.2 Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5.1 Voordelen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6 Voorbeelden van fouten bij softwareprojecten (oefeningen) . . . . . . . . . . . . . . . . . . . . . . . 8
2.6.1 Year 1990 bug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6.2 Leap-year bug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6.3 Interface misuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6.4 Late and over budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6.5 On-time delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6.6 Unnecessary complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Hoofdstuk 3: Behoeftenanalyse 10
3.1 Vereisten/behoeften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1 Verschillende soorten actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2 Hoe lezen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.3 Use case: Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4 Activity diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.1 Bouwstenen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.2 Stappenplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 Testscenario’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Hoofdstuk 4: Domeinmodel 18
4.1 Doel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2 Onderdelen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.1 Conceptuele klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.2 Associaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.3 Generalisatie/specialisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.4 Aggregatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.5 Compositie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.5 Associatieklasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3 Stappenplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.1 Identificeren van de kandidaatsklassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.2 Selecteren van de conceptuele klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3.3 Associaties leggen en/of aanpassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3.4 Attributen toevoegen, verplaatsen en/of schrappen . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.5 Optimalisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.4 Oefeningen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Hoofdstuk 5: System Sequence Diagram (SSD) & Operation Contract (OC) 27
5.1 Doel van systeem sequentiediagram (SSD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2 Onderdelen van systeemsequentiediagram (SSD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2
, 5.2.1 Deelnemer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.2 Levenslijn per deelnemer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.3 Systeemoperatie(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.4 Antwoord op een systeemoperatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.5 Herhaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.6 Externe use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.3 Stappenplan om een systeemsequentiediagram (SSD) op te stellen . . . . . . . . . . . . . . . . . . 30
5.4 Doel van Operation Contract (OC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.5 Onderdelen van een Operation Contract (OC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.5.1 Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.5.2 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.5.3 Cross references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.5.4 Precondities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.5.5 Postcondities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.6 Stappenplan om een Operation Contract (OC) op te stellen . . . . . . . . . . . . . . . . . . . . . . 32
3
, SOFTWARE ANALYSIS
Software Analysis
Andere
• Op Chamilo onder Documenten , staan oefeningen voor in werkcolleges (geen modeloplossingen)
• Leerpad (Per hoofdstuk theorie):
∘ Theorie slides
∘ Begeleidende tekst: extra uitleg/aanvullende nota’s bij de slides.
■ Geen één op één uitleg van de slides. Alles staat wel uitgelegd in de tekst, maar op een andere
manier/volgorde
∘ Uitgewerkte oefeningen (slides) stap voor stap met modeloplossing
• Alles wordt ook beschouwd als te kennen leerstof
∘ Het is mogelijk dat er één of twee extra pdf’s op Chamilo worden gezet dat we niet konden zien in
de les. Deze zijn ook leerstof
Evaluatie
• 85% - Schriftelijk examen gesloten boek
∘ Theorie vragen:
■ Bespreek agile, …
■ Meerkeuze schemas
■ Er komen ook theorie vragen uit H6, dat dus ook leren
■ …
∘ Alle mogelijke schema’s worden gevraagd en moeten kunnen getekend wordent
• 15% - Ontwerp taak
∘ Opdracht staat onder Documenten/UI Taak
∘ Groepjes van 4
■ Module Cursusgroepen op Chamilo
∘ Een mockup maken van hoe een website er moet uitzien. Enkel mockup, niks echt maken in html/css
∘ Je moet de taak indienen, anders ben je gebuisd (wordt gezien als afwezig) voor het volledige vak
∘ Er wordt alleen gekeken naar de laatste indiening, je kan dus zeker op voorhand al eens indienen
∘ Indienen bij Opdrachten
■ Je kan ook controleren als teamgenoten al hebben ingediend
■ Altijd namen + klasgroep erbij
2de kans is nieuwe taak + examen opnieuw
4
, HOOFDSTUK 1: INLEIDING
Hoofdstuk 1: Inleiding
Nothing of note
5
, HOOFDSTUK 2: SOFTWARE-ONTWIKKELINGSPROCES
Hoofdstuk 2: Software-ontwikkelingsproces
2.1 Inleiding
Elk software-ontwikkelingsproces bestaat uit drie basiselementen:
• Scope (features, functionality)
• Resources (kost, budget)
• Schedule (tijd)
Binnen die 3 moet er een goeie afweging worden gemaakt. Een product moet voldoende functionaliteit hebben,
maar dient toch binnen een bepaalde tijd/kost geleverd worden.
Van alle functionaliteiten dient een analyse gemaakt te worden. Zodat er gefocused kan worden op wat voor de
klant de meeste waarde heeft binnen diens budget/tijd.
De scope van het project bevat dan alle te realiseren functionaliteiten.
2.2 Hoe verloopt een project
Eenmaal de scope, middelen (resources) en budget vastliggen, kunnen we nog niet onmiddelijk beginnen on-
twikkelen.
Om het project de meeste kansen op slagen te geven is het nodig om minstens volgende stappen uit te werken:
• (Requirements/vereisten verzamelen)
• Analyse
• Ontwerp
• Programeren
• Testen
• Integratie
∘ Dit is slechts van toepassing als we functionaliteit toevoegen aan reeds bestaande software.
• (Onderhoud)
Dingen tussen haakjes heb ik toegevoegd uit de les, stond niet in begeleidende tekst
2.3 Rollen
Een team dat het project uitwerkt bestaat uit:
• Analist
• Ontwerper
• Programmeur
• Tester
• Projectleider
De volgende behoren niet rechtsreeks tot het team maar spelen wel een belangrijke rol:
• Klant/opdrachtgever
• Managment/business
2.3.1 Projectleider
• Deze persoon leidt het project.
• Beslist of het project wordt verder gezet of niet.
• Verzorgt juiste communicatie naar het team + klant + management
2.3.2 Analist
• Deze persoon zorgt voor de correcte vertaling van de eisen(requirements) van de klant, waaraan het
eindproduct moet voldoen.
∘ Als de analist de eisen niet goed capteert, zal dit in latere fasen in het project leiden tot fouten alleen
maar groter worden.
6
,2.4 Methodes HOOFDSTUK 2: SOFTWARE-ONTWIKKELINGSPROCES
∘ Moet zorgen dat ontwerpers aan slag kunnen met de eisen.
■ AKA niet-technologisch communiceren met de klant, maar wel met de ontwerpers.
Voorbeeld van het belangrijkste schema, en dus communicatiemiddel, is het domeinmodel.
2.3.3 Ontwerper
• Zet de niet technische stukken die gebruikt worden om met de klant te communiceren, om naar diepgaan-
dere documenten die de programmeurs kunnen gebruiken.
Voorbeeld van zo een document, is een sequence diagram met bijhorende operation contracts.
2.3.4 Programmeur
• Zet de documenten van de analist en ontwerper om in code met klassen en methoden om het product met
alle functionaliteiten te verwezenlijken.
2.3.5 Tester
• Moet de fouten vinden in een programma, voor de release van het programma.
Vanuit de analyse, is het voornaamste document dat de tester kan gebruiken het activity diagram. Omdat
dit alle mogelijke wegen beschrijft die het programma kan volgen bij het uitvoeren van de functionaliteiten.
2.4 Methodes
2.4.1 Waterval methode
• Bedoelt om projecten in één keer af te werken
• Je doet alles in opeenvolgende volgorde, je begint eerst bij de analyse, dan ontwerp enz.
• Je doet elke blok in één keer, je kan niet terug.
∘ Dit is niet optimaal, de kans dat het project voldoet aan de eisen van de klant is klein.
Dit leidt tot hoge kosten als het project alsnog aangepast zou moeten worden.
Voor kleine projecten van maximum 3 maanden, kan de waterval methode voor projecten echter wel nog goed
werken.
2.4.1.1 Nadeel De klant is eigenlijk niet meer betrokken bij het project, slechts in het begin. Maar eenmaal
die eerste klant/requirements stap is afgerond, check je niet meer met de klant.
Daarom dat het bij korte/kleine projecten wel goed werkt, omdat in 3 maanden tijd de klant niet echt van
gedacht zal veranderen. Maar bij langere projecten is het beter om voor de Agile manier te gaan.
2.4.2 Agile
Agile werd ontwikkelt om het grootste probleem van de waterval methode, gebrekkige communicatie met de
klant, weg te werken.
Agile deelt een project op in kleinere stukken (=iteraties), hierdoor kan er makkelijk ingespeeld worden op
wijziginen doorheen het project.
Per iteratie worden er doelen (=milestones) vastgelegd die het product moet kunnen op het einde van de iteratie.
De feedbackloop proberen we zo kort mogelijk te houden, 2-6 weken.
Agile is gebouwd rond 2 pijlers:
• Iteratief
∘ We zullen het software-ontwikkelingsproces een aantal keer herhalen om zo het project in kleinere
stukken af te werken.
∘ Voor elk stuk van het project, worden de functionaliteiten steeds ontwikkelt op de volgende manier:
■ Analyse
■ Ontwerp
■ Implementatie
■ Testen
■ Integratie
7
,2.5 UML HOOFDSTUK 2: SOFTWARE-ONTWIKKELINGSPROCES
Aangezien we steeds in kleine stukjes werken die worden geintegreerd in de rest van het project.
Kunnen we eventuele probelemen veel gemakkelijker oplossen.
∘
• Incrementeel
∘ We zullen een project stap per stap(per iteratie) uitbreiden met nieuwe functionaliteiten, in plaats
van alles in één keer te ontwikkelen.
■ Dit zorgt ervoor dat de klant snel werkbare software heeft en zo ook betere feedback kan geven.
□ Dit in tegenstelling tot de watervalmethode, waar de klant pas feedback kan geven wanneer
het product is afgewerkt.
Als er bij de Waterfall aanpak een probleem optreedt, dan moet je helemaal opnieuw beginnen.
Bij Agile werk je in stapjes, dus je kan direct ingrijpen vanaf dat het misloopt.
2.5 UML
Unified Modeling Language
• Een modelleertaal om objectgeoriënteerde analyses en ontwerpen voor een informatiesysteem te kunnen
maken.
• UML zelf is geen methode, maar een notatiewijze die bij verschillende methodes (zoals Iteratief-
Incrementeel) kan worden gebruikt.
2.5.1 Voordelen
UML is een model dat we zullen gebruiken om de werkelijkheid te modelleren, te abstraheren tot wat we strikt
nodig hebben.
• Communicatie
• Visualisatie
• Transformatie = UML vergemakkelijkt de overgang van:
∘ Analyse ⇒ ontwerp
∘ Ontwerp ⇒ programmeren
∘ Programemren ⇒ testen
2.6 Voorbeelden van fouten bij softwareprojecten (oefeningen)
Bepaal per voorbeeld welke rol(len) het meeste in de fout zijn gegaan:
De rollen die in fout kunnen zijn:
• Klant
• Analist
• Ontwerper
• Programmeur
• Tester
• Project leider
2.6.1 Year 1990 bug
In 1992, Mary from Winona, Minnesota, received an invitation to attend a kindergarten. Mary was 104 at the
time.
In fout:
• Ontwerper
∘ De leeftijd in de databank die ontworpen is door de ontwerper, berekend de leeftijd op basis van de
laatste 2 cijfers van het jaartal. Dit is een foute beslissing van de ontwerper.
• Tester
∘ De tester had moeten testen wat er gebeurt als mensen ouder zijn dan 100 jaar
2.6.2 Leap-year bug
A supermarket was fined $1000 for having meat around 1 day too long, on February 29, 1988. The computer
program printing the expiration date on the meat labels did not take into account that 1988 was a leap year.
8
,2.6 Voorbeelden van fouten bij softwareprojectenHOOFDSTUK
(oefeningen) 2: SOFTWARE-ONTWIKKELINGSPROCES
In fout:
• Programmeur
∘ Moet ervoor zorgen dat de berekening van de houdsbaarheids datum altijd klopt, ook als er schrikkel-
jaren zijn
• Tester
∘ Had moeten testen met schrikkeljaren
2.6.3 Interface misuse
On April 10, 1990, in London, an underground train left the station without its driver. The driver had taped
the button that started the train, relying on the system that prevented the train from moving when doors were
open. The train operator had left his train to close a door which was stuck. When the door was finally shut,
the train simply left.
In fout:
• Klant
∘ De klant is koning, dus ookal is die in fout mag je die nooit de schuld geven.
• (Analist)
∘ Had moeten aangeven aan de klant dat de veiligsheid procedure niet zo veilig is.
• Tester
2.6.4 Late and over budget
In 2002, the Swanick Air Traffic Control system covers all the enroute air traffic over England and Wales. The
system was delivered substantially over budget (cost £623 million, originally planned at £350 million) and 6
years late. Two major upgrades of the system were delivered after training of the traffic controllers had started.
In fout:
• Project leider
∘ Heeft de kosten & looptijd van project niet goed ingeschat
• Programmeur
∘ “Er waren nog 2 major upgrades nodig” wat betekent dat er nog redelijk wat bugs waren
2.6.5 On-time delivery
After 18 months of development, a $200-million system was delivered to a health insurance company in Wisconsin
in 1984. However, the system did not work correctly: $60 million in overpayments were issued. The system
took 3 years to fix.
In fout:
• Analist
• Ontwerper
• Programmeur
• Tester
Aangezien er geen specifieke details gekend zijn waarom het systeem niet correct werkte kunnen we hier niet
een bepaalde rol verantwoordelijk maken
2.6.6 Unnecessary complexity
The C-17 cargo plane by McDonnell Douglas ran $500 million over budget because of problems with its avionics
software. The C-17 included 19 onboard computers, 80 microprocessors, and 6 different programming languages.
In fout:
• Klant
∘ Systeem is te complex, maar klant is koning dus hij kan niet in fout zijn
• Ontwerper
∘ Aangezien alles te complex gemaakt werd, b.v. door 6 verschillende programmeertalen, kunnen we
er vanuit gaat het systeem niet goed ontworpen werd.
9
, HOOFDSTUK 3: BEHOEFTENANALYSE
Hoofdstuk 3: Behoeftenanalyse
Figure 1: Use cases te kennen leerstof
3.1 Vereisten/behoeften
Vereisten zijn de behoeften van de klant waaraan het project moet voldoen.
Deze kunnen opgedeeld worden in twee categorieën:
• Functionele vereisten
∘ Functionele vereisten zijn de eisen die beschrijven wat het programma moet kunnen. I.e. welke
functionaliteiten beschikbaar zullen zijn op het systeem.
• Niet-functionele vereisten
∘ Niet-functionele vereisten beschrijven daarentegen hoe het systeem die functionele vereisten moet
uitvoeren of hoe ze er moeten uitzien. Deze vereisten hebben geen invloed op het functionele ontwerp
van het systeem zelf.
Voorbeeld auto:
• Functionele vereisten:
∘ Gas geven
∘ Schakelen
∘ Richting aangeven
∘…
• Niet-functionele vereisten
∘ HOE gas geven (met pedaal of knop op stuur)
∘ Automatische of manuele versnellingsbak
∘ Kleur van richtingaanwijzer
∘…
3.2 Use case
Een use case is een tekstuele beschrijving van een taak voor een bepaalde partij. Het beschrijft het gebruik (=
de interactie tussen actor en systeem) van het systeem om een bepaald doel te verwezenlijken.
Hierin is het belangrijk dat alle acties die het systeem moet uitvoeren om een taak te realiseren duidelijk
beschreven worden. Een use case beschijft alleen maar wat het systeem moet doen, niet hoe het dit moet
uitvoeren.
Dit is een document dat begrijpbaar moet zijn voor alle belanghebbende partijen. Het is met andere woorden
geen technisch document om communicatie met de klant te vereenvoudigen. De use case zelf is een contract
tussen de belanghebbende partijen en het ontwikkelteam.
3.2.1 Verschillende soorten actors
Primary actor Dit is de actor die het verhaal (use case) zal starten en dus als doel heeft om de functionaliteit
te verwezenlijken.
Supporting actor Om zijn doel te bereiken, heeft de primary actor soms nood aan een andere actor die
een bepaald subdoel verwezenlijkt om het totale doel te bereiken. Die andere actor wordt de supporting actor
10
The benefits of buying summaries with Stuvia:
Guaranteed quality through customer reviews
Stuvia customers have reviewed more than 700,000 summaries. This how you know that you are buying the best documents.
Quick and easy check-out
You can quickly pay through credit card or Stuvia-credit for the summaries. There is no membership needed.
Focus on what matters
Your fellow students write the study notes themselves, which is why the documents are always reliable and up-to-date. This ensures you quickly get to the core!
Frequently asked questions
What do I get when I buy this document?
You get a PDF, available immediately after your purchase. The purchased document is accessible anytime, anywhere and indefinitely through your profile.
Satisfaction guarantee: how does it work?
Our satisfaction guarantee ensures that you always find a study document that suits you well. You fill out a form, and our customer service team takes care of the rest.
Who am I buying these notes from?
Stuvia is a marketplace, so you are not buying this document from us, but from seller TomDeBakker. Stuvia facilitates payment to the seller.
Will I be stuck with a subscription?
No, you only buy these notes for $5.87. You're not tied to anything after your purchase.
Can Stuvia be trusted?
4.6 stars on Google & Trustpilot (+1000 reviews)
53022 documents were sold in the last 30 days
Founded in 2010, the go-to place to buy study notes for 14 years now