Uitgewerkte Software Architectuur

[Droned]

Voor mijn studie moet ik een opdracht vervullen, namelijk een casus maken over een eigen verzonnen systeem.

De casus moet alle onderdelen van software engineering bevatten zoals bv:

- Use Cases
- Use case beschrijving
- Klasse diagram
- Toestands diagram
- Sequentie diagram
- Deployment diagram

Het moet alle stadia doorlopen zoals analyse, design en implementatie. Nu ben ik dus op zoek naar een voorbeeld van een volledig uitgewerkte casus. Mag van elk soort programma zijn, maar heb me al rot gezocht op het internet en vind geen document waarin dit allemaal uitgewerkt is.

Wel kleine stukjes zoals een statechart enz vind je wel op het internet maar ik vind het vervelend dat ze dan nooit met dezelfde gegevens verder werken.

Indien iemand er eentje heeft liggen, zou ik deze eens mogen bekijken? Als je er een kleine vergoeding voor wil, wil ik deze wel altijd geven. Zo krijg ik een idee hoe ik te werk moet gaan en hoe het er eventueel moet komen uit te zien in een eindfase.

[NMe]

Ik begrijp dat het fijn is om een compleet voorbeeld te hebben, maar kun je dat écht niet zelf aan elkaar verzinnen als je bijvoorbeeld een pagina als deze doorleest? Als je weet hoe de losse diagrammen in elkaar steken, dan kun je ze ook maken, toegepast op één casus. Als je dezelfde casus gebruikt voor elk diagram, dan heb je geen voorbeeld nodig en heb je je opdracht al af.

[Droned]

Ok, maar zit nog met enkele problemen bij de uitwerking. In de opdracht moet ook nog komen :

* Logisch databaseontwerp en terugkoppeling naar het klassediagram
* Groeperen van databasebewerkingen in transacties
* MVC met en zonder persistentie
* Access controle
* Globale control flow

Nu is mijn vraag of hier ook speciale schema's voor zijn om dit weer te geven, of dat dit louter tekst is die moet geschreven worden om dit weer te geven...

Heb op het internet al over transacties gezocht maar vindt hier niets over.

[JKVA]

Droned schreef op vrijdag 02 januari 2009 @ 11:32:
Ok, maar zit nog met enkele problemen bij de uitwerking. In de opdracht moet ook nog komen :

* Logisch databaseontwerp en terugkoppeling naar het klassediagram
* Groeperen van databasebewerkingen in transacties
* MVC met en zonder persistentie
* Access controle
* Globale control flow

Nu is mijn vraag of hier ook speciale schema's voor zijn om dit weer te geven, of dat dit louter tekst is die moet geschreven worden om dit weer te geven...

Misschien dat het nu nog niet duidelijk is, maar het gaat niet om het maken van de diagrammen. Diagrammen zijn een middel voor het documenteren van je architectuur. Als je iets met tekst kunt omschrijven, zoals: "Er wordt gebruikgemaakt van de Core J2EE Antipatterns", incl. referentie, heb je meer beschreven dan je ooit in een diagram past. In zo'n geval moet je niet voor een diagram kiezen.

Ook het groeperen van database calls in transacties zou ik niet helemaal uitspecificeren. Als je een nette lagenopdeling maakt (zoals: UI, Service, Domain en Data) kun je volgens mij prima volstaan met de noot dat de transactiegrens op de servicelaag ligt.

Access controle kun je ook prima heel beknopt beschrijven, zeker als je gebruikmaakt van een bestaand platform zoals JAAS (in het geval van Java). In dat geval kun je hooguit vastleggen dat je gebruikmaakt van declaratieve security op URL's, inclusief eventueel de gebruikersrollen die je onderkent.

Dat wil niet zeggen dat je geen diagrammen moet tekenen. Een datamodel en een klassediagram zijn allebei heel nuttig. Je moet ze alleen daar gebruiken waar ze meerwaarde hebben.

Heb op het internet al over transacties gezocht maar vindt hier niets over.

Dat lijkt me sterk. Wikipedia: Database transaction

[Creepy]

Droned schreef op vrijdag 02 januari 2009 @ 11:32:
Nu is mijn vraag of hier ook speciale schema's voor zijn om dit weer te geven, of dat dit louter tekst is die moet geschreven worden om dit weer te geven...

Eeeh, waarom niet aan je docent vragen? Daar issie tenslotte ook voor.....

[NMe]

Droned schreef op vrijdag 02 januari 2009 @ 11:32:
* MVC met en zonder persistentie

MVC is een design pattern, geen model/ontwerptekening. Je kán MWC wel uittekenen in bijvoorbeeld een klassendiagram natuurlijk.

[MicroWhale]

Droned schreef op zaterdag 27 december 2008 @ 16:08:
Voor mijn studie moet ik een opdracht vervullen, namelijk een casus maken over een eigen verzonnen systeem.

De casus moet alle onderdelen van software engineering bevatten zoals bv:

- Use Cases
- Use case beschrijving
- Klasse diagram
- Toestands diagram
- Sequentie diagram
- Deployment diagram

Het moet alle stadia doorlopen zoals analyse, design en implementatie. Nu ben ik dus op zoek naar een voorbeeld van een volledig uitgewerkte casus. Mag van elk soort programma zijn, maar heb me al rot gezocht op het internet en vind geen document waarin dit allemaal uitgewerkt is.

Wel kleine stukjes zoals een statechart enz vind je wel op het internet maar ik vind het vervelend dat ze dan nooit met dezelfde gegevens verder werken.

Indien iemand er eentje heeft liggen, zou ik deze eens mogen bekijken? Als je er een kleine vergoeding voor wil, wil ik deze wel altijd geven. Zo krijg ik een idee hoe ik te werk moet gaan en hoe het er eventueel moet komen uit te zien in een eindfase.

Een software architectuur document bevat doorgaans geen uitwerkingen van use cases (of andere ontwerpaspecten). Die zitten eerder in het System Design (Document of Specification) of Functioneel Ontwerp.

De software architectuur geeft alle beperkingen en vrijheden waarbinnen de oplossing mag worden ontworpen. Het beantwoordt dus meer de vragen Wat en Waarmee dan de vraag Hoe.

Trouwens: Ik hoop dat dit een stage- of schoolopdracht is. Het maken van een ontwerp of architectuur is niet iets wat je zo 1-2-3 goed in elkaar zet.

[ Voor 4% gewijzigd door MicroWhale op 08-01-2009 12:12 ]

[the_shadow]

Droned schreef op zaterdag 27 december 2008 @ 16:08:
De casus moet alle onderdelen van software engineering bevatten zoals bv:

- Use Cases
- Use case beschrijving
- Klasse diagram
- Toestands diagram
- Sequentie diagram
- Deployment diagram

Het moet alle stadia doorlopen zoals analyse, design en implementatie. Nu ben ik dus op zoek naar een voorbeeld van een volledig uitgewerkte casus. Mag van elk soort programma zijn, maar heb me al rot gezocht op het internet en vind geen document waarin dit allemaal uitgewerkt is.

Mocht je nog een goed boek zoeken over dit onderwerp, dan zou je onderandere kunnen kijken naar Object-Oriented Software Engineering door Lethbridge en Laganiere (ISBN 0-07-710908-2). Dit boek gebruiken we op de Universiteit Twente bij het vak Software Engineering Modellen. Het behandeld het volledige software design traject en je kan het dus goed gebruiken voor de door jou beschreven opdracht.

Verder moet ik me aansluiten bij de reacties hier boven me: zo'n document stel je voor een systeem niet zo 1-2-3 op. Ik heb veel mensen gezien die het geprobeerd hebben, maar helaas komt er 99/100 keer een onsamenhangend verhaal uit.

[_Erikje_]

Gratis en voor niets. De architectuur van het BSN dat KPMG een tijdje geleden heeft gemaakt.

Ze hebben hier nog een of andere prestigieuze architectuur prijs mee gewonnen.
http://www.bprbzk.nl/dsc?...WBNDacG&!dsname=BPRextern

Andere inzendingen van die architectuur wedstrijd:
http://www.nkictarchitectuur.nl/2007/submissions.htm

[ Voor 15% gewijzigd door _Erikje_ op 11-01-2009 21:35 ]

[EfBe]

Droned schreef op zaterdag 27 december 2008 @ 16:08:
Voor mijn studie moet ik een opdracht vervullen, namelijk een casus maken over een eigen verzonnen systeem.

De casus moet alle onderdelen van software engineering bevatten zoals bv:

- Use Cases
- Use case beschrijving
- Klasse diagram
- Toestands diagram
- Sequentie diagram
- Deployment diagram

Het moet alle stadia doorlopen zoals analyse, design en implementatie. Nu ben ik dus op zoek naar een voorbeeld van een volledig uitgewerkte casus. Mag van elk soort programma zijn, maar heb me al rot gezocht op het internet en vind geen document waarin dit allemaal uitgewerkt is.

Wel kleine stukjes zoals een statechart enz vind je wel op het internet maar ik vind het vervelend dat ze dan nooit met dezelfde gegevens verder werken.

Indien iemand er eentje heeft liggen, zou ik deze eens mogen bekijken? Als je er een kleine vergoeding voor wil, wil ik deze wel altijd geven. Zo krijg ik een idee hoe ik te werk moet gaan en hoe het er eventueel moet komen uit te zien in een eindfase.

Je doet die studie om iets te leren. Als je dus iets fout doet dan leer je daar ook van. M.a.w.: hier een voorbeeld opduikelen heeft geen zin, je leert er nl. geen reet van.

_Erikje_ schreef op zondag 11 januari 2009 @ 21:34:
Gratis en voor niets. De architectuur van het BSN dat KPMG een tijdje geleden heeft gemaakt.

Ze hebben hier nog een of andere prestigieuze architectuur prijs mee gewonnen.
http://www.bprbzk.nl/dsc?...WBNDacG&!dsname=BPRextern

Andere inzendingen van die architectuur wedstrijd:
http://www.nkictarchitectuur.nl/2007/submissions.htm

What?! Er zijn mensen die prijzen uitreiken voor software architectuur? Onbegrijpelijk...

[ Voor 20% gewijzigd door EfBe op 12-01-2009 09:06 ]

[D-Raven]

Droned schreef op zaterdag 27 december 2008 @ 16:08:
Voor mijn studie moet ik een opdracht vervullen, namelijk een casus maken over een eigen verzonnen systeem.

De casus moet alle onderdelen van software engineering bevatten zoals bv:

- Use Cases
- Use case beschrijving
- Klasse diagram
- Toestands diagram
- Sequentie diagram
- Deployment diagram

Het moet alle stadia doorlopen zoals analyse, design en implementatie. Nu ben ik dus op zoek naar een voorbeeld van een volledig uitgewerkte casus. Mag van elk soort programma zijn, maar heb me al rot gezocht op het internet en vind geen document waarin dit allemaal uitgewerkt is.

Wel kleine stukjes zoals een statechart enz vind je wel op het internet maar ik vind het vervelend dat ze dan nooit met dezelfde gegevens verder werken.

Indien iemand er eentje heeft liggen, zou ik deze eens mogen bekijken? Als je er een kleine vergoeding voor wil, wil ik deze wel altijd geven. Zo krijg ik een idee hoe ik te werk moet gaan en hoe het er eventueel moet komen uit te zien in een eindfase.

Het opstellen van een software architectuur is moeilijk. Zeker voor iemand die er nog weinig ervaring mee heeft. Als je voorbeelden zoekt betreffende de verschillende diagrammen zul je toch eens naar een UML boek moeten gaan kijken (zoals eerder genoemd).

Ik moet wel zeggen, ik zet wel een aantal vraagtekens bij de dingen je noemt.

Dingen uit het lijstje van "Logisch databaseontwerp en terugkoppeling naar het klassediagram" zijn op zn zachts gezegd maar vaag omschreven. Probeer die eens wat concreter te maken voor jezelf.
Bedenk wel, het doel van wat je gaat doen is het beschrijven van wat je applicatie gaat doen, en waarmee deze dit gaat doen. Of dit nu met plaatjes, diagrammen, filmpjes of puur tekst wordt uitgedrukt is maar bijzaak.

Dus als jij in tekst iets duidelijker beschreven krijgt dan in een of ander diagram dan zou ik voor het eerste gaan. (m.b.t. het 2de lijstje)
Tenzij je leraar daar natuurlijk anders over denkt

[MicroWhale]

EfBe schreef op maandag 12 januari 2009 @ 09:04:
[...]

What?! Er zijn mensen die prijzen uitreiken voor software architectuur? Onbegrijpelijk...

Vind je? Als je leest wat het doel is van het NK, dan wordt het al een stuk duidelijker:

Er zijn mensen die de behoefte hebben om hun architectuur door een onafhankelijke partij te laten beoordelen om te kijken waar zij verbeteringen kunnen aanbrengen. Die behoefte begrijp ik wel, omdat er niet één manier is om een architectuur op te stellen. Architecten vragen zich dus, vaker dan hun collega's, af of ze wel op de goede weg zitten.

[EfBe]

MrWilliams schreef op maandag 12 januari 2009 @ 10:11:
[...]


Vind je? Als je leest wat het doel is van het NK, dan wordt het al een stuk duidelijker:

Er zijn mensen die de behoefte hebben om hun architectuur door een onafhankelijke partij te laten beoordelen om te kijken waar zij verbeteringen kunnen aanbrengen. Die behoefte begrijp ik wel, omdat er niet één manier is om een architectuur op te stellen. Architecten vragen zich dus, vaker dan hun collega's, af of ze wel op de goede weg zitten.

Maar het is zinloos tenzij de partij die het nakijkt het gehele project nog eens over doet. Immers: je kunt alleen de juistheid van een architectuur beoordelen wanneer je jezelf verdiept in alle stakeholders, hun belangen, wensen etc. Aangezien men dat niet doet kijkt men dus naar het pure resultaat, en dan daar een oordeel over vellen is IMHO echt onzin, want of iets goed is of niet is dan niet te beoordelen.

[Verwijderd]

in UML is het geoorloofd om je database diagram als class diagram te schrijven. In principe krijg je dan een diagram zonder methods, dus alleen met properties. Je groeperingen zou je in een sequence diagram kunnen weergeven, etc. Je moet inzien dat UML een hulpmiddel is om iets op te lossen. Hoe en wat je ermee oplost mag je zelf bepalen ( meestal zal het een architectuur zijn ).

Maar het maken van dit soort opdrachten hebben een reden: ze leren je het gebruik van tools als UML. Het downloaden van een compleet uitgewerkt geheel zal je niet verder brengen dan een goede copieerder en ik denk dat dat niet jouw doel is.

mvg,
- dm

[MicroWhale]

EfBe schreef op maandag 12 januari 2009 @ 11:23:
[...]

Maar het is zinloos tenzij de partij die het nakijkt het gehele project nog eens over doet. Immers: je kunt alleen de juistheid van een architectuur beoordelen wanneer je jezelf verdiept in alle stakeholders, hun belangen, wensen etc. Aangezien men dat niet doet kijkt men dus naar het pure resultaat, en dan daar een oordeel over vellen is IMHO echt onzin, want of iets goed is of niet is dan niet te beoordelen.

Inderdaad, alleen de architectuurbeschrijving wordt beoordeeld. Niet het geimplementeerde resultaat. Het gaat er dan ook om dat architecten een heldere, begrijpelijke, eenduidige en volledige (en waarschijnlijk nog wat van die criteria) beschrijving geven als afbakening voor de oplossing. Of deze afbakening goed werkt voor de gewenste oplossing is een aspect dat hier buiten beschouwing blijft omdat dat dat niet getoetst kan worden.

[EfBe]

MrWilliams schreef op dinsdag 13 januari 2009 @ 10:58:
[...]
Inderdaad, alleen de architectuurbeschrijving wordt beoordeeld. Niet het geimplementeerde resultaat. Het gaat er dan ook om dat architecten een heldere, begrijpelijke, eenduidige en volledige (en waarschijnlijk nog wat van die criteria) beschrijving geven als afbakening voor de oplossing. Of deze afbakening goed werkt voor de gewenste oplossing is een aspect dat hier buiten beschouwing blijft omdat dat dat niet getoetst kan worden.

Maar dan beoordeel je toch het expressieve vermogen van de schrijver en niet het architectuur-technische aspect van zo'n ontwerp? Wat de reden is waarom ik het niet snap dat er uberhaupt prijzen worden uitgereikt aan dit soort zaken. Maar goed, off topic

Het zou mooi zijn als de topicstarter zijn mening zou geven over wat al gezegd is in deze thread.

[_Erikje_]

EfBe schreef op maandag 12 januari 2009 @ 11:23:
[...]

Maar het is zinloos tenzij de partij die het nakijkt het gehele project nog eens over doet. Immers: je kunt alleen de juistheid van een architectuur beoordelen wanneer je jezelf verdiept in alle stakeholders, hun belangen, wensen etc. Aangezien men dat niet doet kijkt men dus naar het pure resultaat, en dan daar een oordeel over vellen is IMHO echt onzin, want of iets goed is of niet is dan niet te beoordelen.

Dat is natuurlijk grote kul. Een project helemaal overdoen is een belachelijk idee omdat het succes van een project niet alleen aan de architectuur te danken is.
Daarnaast zijn er meerdere (goed werkende) technieken om architecturen te valideren zoals ATAM die de architectuur toetsen op hoe goed ze de requirements verwerken.

on-topic: Misschien nog interessant, een paper die beschrijft dat je met 5 views (diagrammen) een architectuur goed kan beschrijven: http://www.google.nl/url?...g2=km0gLUqm8RXTmRpE4S083A

[ Voor 18% gewijzigd door _Erikje_ op 13-01-2009 15:28 . Reden: ontopic shit ]

[EfBe]

_Erikje_ schreef op dinsdag 13 januari 2009 @ 15:27:
[...]

Dat is natuurlijk grote kul. Een project helemaal overdoen is een belachelijk idee omdat het succes van een project niet alleen aan de architectuur te danken is.

zucht...
Je snapt het niet, mijn punt is dat wanneer je een architectuur document bekijkt, daar dus de eindresultaten instaan, maar de stakeholders en opdrachtgevers willen wellicht heel wat anders. Dus om te beoordelen of de architectuur goed is (== dus wat de stakeholders/opdrachtgevers nodig hebben) is niet te bepalen aan de hand van een docje.

Daarnaast zijn er meerdere (goed werkende) technieken om architecturen te valideren zoals ATAM die de architectuur toetsen op hoe goed ze de requirements verwerken.

En hoe ga jij toetsen of de requirements uberhaupt goed zijn bepaald? De requirements afleiden aan de hand van het eindresultaat is een circulaire redenatie!

on-topic: Misschien nog interessant, een paper die beschrijft dat je met 5 views (diagrammen) een architectuur goed kan beschrijven: http://www.google.nl/url?...g2=km0gLUqm8RXTmRpE4S083A

Rational Corp. wil uiteraard aangeven dat je met modellen en views een architectuur goed kunt weergeven. Echter, dat is mosterd na de maaltijd: immers het hele punt is nu juist het bepalen WAT je gaat definieren als je architectuur en WAAROM (en dus ook, waarom andere zaken juist niet gekozen zijn). Models hoe de uiteindelijke architectuur eruit ziet is leuk voor de mooie plaatjes, maar vertelt je niets over hoe men daartoe gekomen is. En dat is nu juist wat topicstarter moet leren met deze opdracht en hij/zij dus niet leert door hier wat te gaan vragen.

[ Voor 32% gewijzigd door EfBe op 13-01-2009 16:29 ]

[TheBigBug]

Kijk eens op http://www.iconixsw.com/. Iconix is een methode om op een praktische manier met behulp van UML door een software engineering traject heen te gaan. Iconix wordt ondersteund door de UML-tool Enterprise Architect van Sparxsystems, da's ook meteen een goede tool om te gebruiken voor de opdracht. Goed en niet al te duur.

Verder denk ik dat je wat zou kunnen hebben aan een boek over UML. Ik heb Learning UML 2.0 van O'reilly. Met behulp van deze twee boeken zou je een eind moeten kunnen komen.

Een onderwerp om te engineeren moet niet zo heel moeilijk te vinden zijn, zeker als je zelf alle rollen in mag vullen. Voorbeeldje van dingen die het altijd goed doen zijn boekingssystemen (camping of hotel) of een programma voor een makelaar, met daarop huizen, prijzen e.d.

Iconix boek:
http://www.amazon.com/dp/...did=0BR4SPM8D7C3V0XD3DDX&

UML boek:
http://oreilly.com/catalog/9780596009823/

Succes met de opdracht!

Ps. Oh ja, diagrammen om database relaties in weer te geven heten ER-diagrammen, waarbij ER staat voor Entity-relationship. Check Wikipedia hiervoor: Wikipedia: Entity-relationship model

[ Voor 18% gewijzigd door TheBigBug op 13-01-2009 21:01 . Reden: Enterprise Architect en ps. toegevoegd ]