Created by Dennis Pražák
modules are logically decomposed into smaller ones until small enough
module = implementation unit with responsibilities
relationships between modules - part of, depends on (uses), is-a
it is a development-time viewpoint
how modules use other modules
(calls, uses, is-allowed-to-use, depends on)
is-a relationship
(re-use and incremental addition of functionality)
runtime viewpoint
helps reason about runtime qualites (availability, security...)
components, connectors, hardware communication elements (allocated to)
performance, security, availability reasoning
modules, file structure (implemented in)
for development activities, build prcoess
modules, people or teams (work assignment)
important for project management
decomposition of system to key functional modules (classes, services) and their attributes and methods
package diagrams, class diagrams
key internal behavior of functional modules
state machine diagrams
functionality as runtime processes
process = group of related tasks
task = executable unit which is performed by some unit from functional viewpoint
sequence diagrams, activity diagrams
decomposition to elements developed and tested by development teams with defined interfaces and what other modules a module can use
component diagrams
assigns functional and process elements to physical configurations
deployment diagram
describe system behavior as seen by stakeholders
use case = requirement expressed as interaction with the system
discuessed last, created first
use case diagrams
reliability + ability to recover
failure = observable by other systems and users
fault = problem occured but isn't observable -- not an availability problem
types of fault - omission, crash, incorrect timing, incorrect response
measurable or testable property of a system that is used to indicate how well the system satisfies a