User:Antonystang/sandbox
Appearance
Software Architecture Supporting Activities
[edit]Software architecture supporting activities are activities that are carried out during core software architecture activities. These supporting activities assist a software architect to carry out analysis, synthesis, evaluation and evolution. For instance, an architect has to gather knowledge, make decisions and document during the analysis phase.
- Knowledge Management and Communication is the activity of exploring and managing knowledge that is essential to architecting. A software architect does not work in isolation. S/he gets inputs, function and non-functional requirements and design contexts, from various stakeholders; and provides outputs to stakeholders. Software architecture knowledge is often tacit and is retained in the heads of stakeholders. Software architecture knowledge management activity is about finding, communicating, and retaining knowledge. As software architecture design issues are intricate and interdependent, a knowledge gap in design reasoning can lead to incorrect software architecture design [1] [2]. Examples of knowledge management and communication activities are search for design patterns, prototyping, ask experienced developers and architects, read design from similar systems, share knowledge with other designers and stakeholders, document experience in a wikipage.
- Design Reasoning and Decision Making is an activity of reasoning with information to make an evaluated design decision. This activity is fundamental to all three core software architecture activities [3] [4]. It entails gathering and associating decision contexts, formulating design decision problems, finding solution options and evaluating tradeoffs before making decisions. This process happens at different levels of decision granularity, in reasoning about architectural significant requirements and software architecture decisions and groups of decisions, during software architecture analysis, synthesis, and evaluation. Examples of reasoning activities are understanding the impacts of a requirement or a design on quality attributes, questioning the issues that a design might cause, assessing possible solution options, evaluating the tradeoffs between solutions.
- Documentation is the activity of recording the design generated during the software architecting process. This documentation can be formal if it is to be used by other stakeholders than the designers or it can be informal if it is intended only for use during the design process. The amount of formality used in the documentation is a function of the cost of producing the documentation and the perceived benefit of having it. A system design is described using several views that frequently include a static view that shows the code structure of the system, a dynamic view that shows the actions of the system during execution, and a deployment view that shows how a system is placed on hardware for execution. Kruchten's 4+1 view suggests a description of commonly used views for documenting software architecture [5]; Documenting Software Architectures: Views and Beyond has descriptions of the kinds of notations that could be used within the view description. [6]. Examples of documentation activities are writing a specification, recording a system design model, documenting a design rationale, developing a viewpoint, documenting views.
References
[edit]- ^ Babar, M.A. (2009). Software Architecture Knowledge Management:Theory and Practice (eds.), First Edition. Springer. ISBN 978-3-642-02373-6.
{{cite book}}
: Unknown parameter|coauthors=
ignored (|author=
suggested) (help) - ^ Kruchten, P. (2008). "What do software architects really do?". Journal of Systems and Software. 81 (12): 2413–2416. doi:10.1016/j.jss.2008.08.025.
- ^ Jansen, A.; Bosch, J. (2005). "Software Architecture as a Set of Architectural Design Decisions". 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05). p. 109. doi:10.1109/WICSA.2005.61. ISBN 0-7695-2548-2.
- ^ Tang, A.; Han, J.; Vasa, R. (2009). "Software Architecture Design Reasoning: A Case for Improved Methodology Support". IEEE Software. 26 (2): 43. doi:10.1109/MS.2009.46.
- ^ Kruchten, Philippe (1995, November). Architectural Blueprints — The “4+1” View Model of Software Architecture. IEEE Software 12 (6), pp. 42-50.
- ^ Clements, Paul (2010). Documenting Software Architectures: Views and Beyond, Second Edition. Boston: Addison-Wesley. ISBN 978-0-321-55268-6.
{{cite book}}
: Unknown parameter|coauthors=
ignored (|author=
suggested) (help)