Samenvatting modelling and design (5071MOON6Y)

Modelleren en ontwerpen
Hoorcollege week 1

Domain modelling
●​ Waarom → domein modelleren helpt bij het identificeren van relevante concepten en
ideeën over een domein
●​ Wanneer → op ieder moment dat je een (beter) begrip nodig hebt van de concepten
in een domein
●​ Richtlijn → creëer een domein model voor het doel dat je op dat moment hebt, voor
het vraagstuk waar je op een bepaald moment voor staat



types of modelling:
●​ implementation modeling → over de werking van (delen van) een IS;
○​ vb. database model
●​ specification modeling→ over de eisen (requirements) aan een IS;
○​ vb. use case diagram
○​ niet over concrete implementatie
●​ domain modelling→ over een situatie, een domein is de werkelijkheid;
○​ vb. business model
○​ niet over een IS
○​ also called business modelling
○​ Dient om een goed beeld/model van het domein, bijvoorbeeld een
○​ organisatie te krijgen.
●​ all models are wrong, but some are useful


Waarom aandacht voor domein modelleren?
●​ als je een IS gaat ontwikkelen is het essentieel dat je het domein, bijv. de organisatie
begrijpt
○​ om user requirements echt goed te begrijpen dien je de organisatie te
begrijpen:
■​ passen de eisen wel binnen de specifieke organisatie en beleid?
■​ wat is de positie van de user in de organisatie?
○​ domein voor een gemeenschappelijk beeld/model van de organisatie →
essentieel in communicatie en identificatie van de mogelijkheden bijv. voor
een IS

,Problemen in systeemontwikkeling
●​ Complexity → systemen zijn complex, fundamenteel omdat (business) werkelijkheid
erg complex is
●​ Conformity → geen systeem is een island, elk systeem is ingebed in een (business)
werkelijkheid
●​ Changeability → omgevingen veranderen, eisen veranderen, gebruikers veranderen
etc → (business) werkelijk is niet stabiel
●​ Invisibility → de manieren waarop systemen functioneren zijn moeilijk om te
visualiseren; functioneren van een systeem wordt onzichtbaar


Model Driven Development (MDD)
●​ complexe applicaties en systemen ontwikkelen op basis van conceptuele modellen
●​ Identificeren van problemen en mogelijkheden in een complexe context
●​ promoting communication, through design artefacts



UML
1.​ Structure
2.​ Behaviour
3.​ Interaction (afgeleid van behaviour)

●​ UML heeft beperkingen op Enterprise niveau
●​ Veranderingen op business environment niveau lastiger te borgen in UML
●​ UML heeft sterke technische verbinding
●​ UML heeft steke onderverdeling in te modelleren aspecten

, Kennisclip: Objects and classes

Object
●​ Individu in een systeem
●​ Bepaalde instantie die zich in een systeem of domein bevindt
●​ Object bevindt zich in een class
●​ Anonymous objects → no object name
●​ Attribute with current value


Object Diagram
●​ Objects of a system and their relationships
●​ Snapshot of objects at a specific moment in time
●​ Lijnen tussen objecten → links
●​ Instanties van classes


From Object to Class
●​ Individuals of a system often have identical characteristics and
behaviour
●​ A class is a construction plan for a similar objects of a system
●​ Objects are instances of classes
●​ Attributes → structural characteristics of a class
○​ Different value for each instance(object)
●​ Operations → behaviour of a class
○​ Identical for all objects of a class → not depicted in object
diagram


Class
●​ Class name → altijd in het enkelvoud
○​ Vb. Course
●​ Attributes
○​ Vb. name: String
●​ Operations
○​ Vb. getCredits(): int

, Attribute Syntax




●​ Visibility → wordt aangegeven voor het attribuut
○​ Who is permitted to access the attribute
■​ + → public (iedereen)
■​ - → private (only the class itself)
■​ # → protected (class itself and subclasses)
■​ ~ → package (classes that are in the same package)
●​ / → staat voor age
○​ Attribute value is derived from other attributes
■​ Age → calculated from date of birth
●​ Name of the attribute
○​ Staat altijd voor de dubbele punt
●​ Type → na de dubbele punt
○​ User-defined classes
○​ Data type
■​ Primitive data type
●​ Pre-defined → boolean, integer, UnlimitedNatural, String
●​ User defined → <<primitive>>
●​ Composite data type → <<datatype>>
■​ Enumerations → <<enumeration>>
●​ Multiplicity
○​ Number of values an attribute may contain
○​ Default value → 1
○​ Notation → [min..max]
■​ No upper limit: [ * ] or [0.. *]
●​ Default value
○​ Used if the attribute value is not set explicitly by the user
●​ Pre-defined properties
○​ {readOnly} → values cannot be changed
○​ {unique} → no duplicates permitted
○​ {non-unique} → duplicates permitted
○​ {ordered} → fixed order of the values
○​ {unordered} → no fixed order of the values



Operation Syntax - parameters
●​ Notation similar to attributes
●​ Direction of the parameter
○​ In → input parameter
■​ When the operation is used, a value is expected from this parameter
○​ Out→ output parameter