Which views are differentiated?
- context view
- runtime view
- building block view
- deployment view
Describe the contents of the context view
- describes the environment of a system and the relationships and connections with this environment
- emphasis on interfaces, references to corresponding interface concept should be made
- delimits the scope of the system in question
What are important elements of the context view?
- external actors (adjacent systems and users)
- the system to be developed
- all interfaces to adjacent systems
Description of all interfaces includes:
- type of interface (online, batch, …)
- data or resources passed via interface
- methods or functions used
- communication protocols
- communication patterns used (asynch, synch, …)
Describe the stakeholders of the context view
- lots of stakeholders because interfaces are critically important
May include:
- project management
- requierement analysis (input providers -> ip)
- system analysis (ip)
- Technical or domain expers (ip)
- design and development
- testers
- downstream administration and operations
- controlling
- possibly lot more
What notations are used for context view
- many different notations
- uml component / composite structure diagrams
- for technically focused context views, supplement of UML nodes possible
- power point presentations
In what connection does the context view stand with the other views?
- provides abstract illustration of other views
- their respective notations and diagrams can be used to supplement those of the context view
Describe the contents of the building block view
- during development: desired structure
- once in production: real-world structure of the system
- Aim: explicitly show building blocks of the system and their relationships inbetween
- can be developed in top-down approach, starting from context view
- if integration is needed, top-down approach may be supplemented by bottom-up abstraction of these systems
In the building block view what should the description of a building block contain?
- name
- purpose/responsibility
- Interface
- reference to implementation
Other optional attributes may be added
Describe the stakeholders of the building block view
- project staff involved in design, architecture, development and testing of software
- project management staff for activity plans and assistance in development of work
- quality assurance
- staff involved in future maintenance of resulting software
What descriptive elements / notations are used in the building block view?
- UML class and component diagrams
- components most used when external interfaces play significant role
- class diagrams often in refinement
Describe the contents of the runtime view
- describes (dynamic) interactions between the instances of the building blocks at runtime
- includes aspects of system operation like system start, runtime configuration and system administration
Describe the stakeholders of the runtime view
- operators of the software system
- staff involved in architecture, design, development and testing of the software
- system architects
- quality assurance
What are typical descriptive elements of the runtime view
- UML activity, communication and sequence diagrams
- Traditional flow charts
- BPMN for representing business processes
- small sections of (pseude)code
- informal verbal sequence description in form of numbered lists
How are UML communication and sequence diagrams different to each other and to what view to they belong?
- runtime view
- communication diagrams offer more flexibility on how to arrange the diagram, often being easier to understand
- sequence diagrams have clear structure, flow from left to right, making it easier to understand where things start
Describe the contents of the deployment view
- describes details about technical infrastructure, how components are where to be deployed
- assist operation and deployment of the system
- system software belongs visible onto technical nodes/hardware building blocks
- artifacts are assigned to their execution environment
- this assignment can be made 1:1 or m:n
- also mapping of the software system and “reality, e.g. in form of references to build and deploy scripts
Describe the stakeholders of the deployment view
- staff responsible for deployment and operation of the software system
- system architect and software architects
- developers
What are typical descriptive elements in the deployment view
- UML deployment diagrams
- including elements like: channels, UML components/packages used for runtime elements (software systems)
How do interedependencies affect architecture views?
- changes in one view often has impact on other views
- iterative process is desireable in which dependent views are updated following changes
- special interdependencies should be documented
What interdependencies exist usually between architecture views?
- building block view and runtime view are derived from context view and thus dependent
- building block view and runtime view also have a relationship with each other
- deployment view uses building block view elements and exists in a technical context
How does the Hierarchical refinement of architecture views work?
- hierarchy begins with context view, presenting a black box
- level of refinement exposes the overall system as a white box, showing the inner composition out of building blocks
- these inner building blocks are again black boxes that can/should be further refined
- fluid transition to software system design, refinement of modules or components to specific classes
- refinement affects most views, especially building block and runtime view
What is usually part of black box building block descriptions?
- Purpose/task
- Input/output interfaces
- Fulfilles requierements
- Variability
- Performance Characteristics
- Storage location/file (source code)
- other administrative information
- open issues
What is usally part of the white box description?
- Overview diagram
- Local building blocks (list/table)
- Local relationships
- Design decisions
What does the context view focus on in technical vs. functional perspective?
- functional: functional delimitation from other systems
- technical: technical integration into existing or future infrastructure
-
Basic34
-
Designing Software Architectures - Process and Heuristics18
-
Design SA - Architecture centric approaches19
-
Techniques for good Design10
-
Architectural Patterns29
-
Design Patterns15
-
Description and Communication of Software Architectures22
-
Architecture Views23
-
Architecture Documentation and Technical/cross-cutting concepts29
-
Alternative architecture frameworks6
-
Quality and Analysis32
