Please enable JavaScript.
Coggle requires JavaScript to display documents.
system modelling techniques - Coggle Diagram
system modelling techniques
model = representation of a subject
different models focus non different parts od a system
need a combination of models for complete view
system
has a boundary - outside external entities interact with the system
within a system components implement the behaviour
the interactions involve data being exchanged, transformed & stored
system exists in a broader context but defined by how it delivers functionality/services (reqs)
abstraction
removing anything unnecessary / irrelevant
to understand and analyse
classification
basic form of abstraction
defining structure of a class
generalisation
extends classification - don't just group objects into a single class
inc behaviour (operations)
group classes / entities based on common characteristics
composition
number of various objects come together = form a new object
sometimes stakeholders interested in composite object - others need to see component parts
idealisation
various levels
conceptual
structured, high level detail - without implementation
incomplete / not robust
multiple models by different stakeholders
useful for modelling business semantics
logical
more structurally complete / robust - not inc implementation
likely the single view from multi conceptual models
physical
considers implementation
logical model converted into platform specific
model described so that solution can be built
contextual
background for other levels
unstructured representation - helps outline scope & purpose
logical model
remove the how (technology), who (people/BUs) & where (location)
focus on what / when / logical who& why
idealisation
combination of diagrams & structured text
model elements
links & dependencies btwn elements
produce at least 2 versions of each model
current (as is) - baseline model
proposed (to be) - target model
view point
multiple views of a model from differing viewpoints
viewpoint = a template for a view
the U curve
moving from physical as is through abstraction to logical as is to logical to be and then physical to be
rationale for modelling
develop a solution which meets stakeholders reqs
aim = developing a high quality solution
communication & understanding
model = captures/communicates understanding of the system
experimentation
explore alternative designs, what ifs
early prototype = flesh out risks / defects
validation
stakeholder confirmation of reqs understanding and suitability before cost/effort increased
gap analysis
comparison of as is to & to be
ids new elements to meet reqs
changes/removal to existing elements
gaps = planning design/build/test/implementation activities
usefulness = value
collaborative experimentation / validation
fixing defects early on saves time & resource
visual diagrammatical = more obvious to spot 'gaps' / defects
structured / standardised = less ambiguity = interpreted by humans & tools (automation)
model driven architecture (MDA) - mimics/automates
No single model sufficient.....need multiple models to address different concerns .......must be coordinated carefully to ensure that they are consistent .......(Kruchten, 2001)
3 view approach = 3 views of a system
functionality
what the system does / required to do tp process data
who? people/system interaction
logically / physically
internal / external
static data
input, manipulation, storage, & output of data
run time = process dynamic data objects
abstract representation of data objects & structures defined in analysis & design
captures the semantics of data = meaning / integrity rules
events
triggers - reactions by data processing in a predetermined way
potential events need to be identified so that event functionality can be defined
address the who? what? how? when? where?
(why = underlying reqs)
Unified Modelling Language (UML)
Functionality diagrams (page 118)
use case diagram
activity diagrams
interaction diagrams
sequences
communication
timing
interaction overview
static data
class diagram
events
state machine
evolution of Harel's state chart (pg 117)
specifies how to draw use case diagram - not specify what use cases represent or how to document
Cockburn use case levels
use case = description of required interaction btwn actor (user / other system) and system, which is of value to the actor to meet a goal. Incs multi scenarios covering whole story, some where actor suceeds some failure
2 scales
design scope
defines type of system the boundary represents
defines the type of actor and the nature of their interactions
organisation
business system inc manual & IT functionality
actor = person / system outside the org who interacts as described in the use case
black box = int bus fns, it systems, dept - staff not specified
white box - internal elements referred to in the description
system
it system / app
system actor = user or separate it system/app - interacts as per use case description
black box = internal components, sub systems, system architecture not revealed/discussed in description
white box = internal architecture revealed - in description
component
one of there architectural elements revealed in white box system use case
actors = other components
idealisation represented
black box = conceptual / logical
white box = logical / physical - depending on specificity
goal level
actors have different goals - goals not part of system - system is means to goal
summary goal (kite level)
e2e process goal
take place over extended period
involve no people/systems
user goal (sea level)
task performed by single person
1 place, 1 time
eg. transaction
sub goal (fish level)
not meaningful in its own right
only decomposed if significant -reused in several user goal use cases
sea level + = reqs / the why?
sea level - = how?
sea bed level
lines of executable code
too low to model with use cases
black box
not concerned with inner workings
concerned with it as a whole, its links and dependencies on other elements
context diagram = good black box view of whole system
can test independent of how implemented
white box
interested in the internal working
decomposition of black box functionality
testing - performed to identify defects
Functional Model Map (FMM)
used to select model types, at which levels to provide traceability from high level bus reqs to low level tech design
effective - consistency / quality
validating elements back to bus reqs
cross referencing elements btwn models
different views - consistent system scope
models/views conform to same semantics
maintaining/checking mappings
traceability - reqs met or not
how to plan incremental delivery
impact of proposed reqs changes
can highlight
structural inconsistencies - misinterpretation/poor assumptions
change impacts
matrices
maintain / view dependencies
CRUD matrix
created
read
updated
deleted
Unified Process
5 views of a system
start empty - fill up through the project, all full when project completed
4+1 views
logical
functional reqs of system
implementation
organisation of static software/data files/components
process
behaviour at run
deployment
how executable /other run components deployed
use case
bite size deliverables
the +1