Özet. Yazılım mimarisi bakış açıları yazılım mimarilerinin değişik bakış açıları cinsinden modüler bir şekilde kısımlara bölünmesini ve her bir kısımın o bakış açısı ile ilgili tasarım kararlarına odaklanmasını hedefler. Bu bildiride, yazılımcıların değişik bakış açıları üzerine olan bilgi ve tecrübelerini anlamaya yönelik farklı endüstrilerde çalışan 20 farklı ülkeden 56 pratisyenin katıldığı bir anket düzenlenmiştir. Anket, pratisyenler tarafından sıklıkla kullanıldığı düşünülen farklı yazılım mimarisi bakış açılarına odaklanmıştır: mantıksal, davranış, eşzamanlılık, fiziksel, ve dağıtım bakış açıları. Anketten çıkan sonuçların bazı ilginç olanları şöyledir: (i) mantıksal, davranış, fiziksel, ve dağıtım bakış açıları bir hayli ilgi görürken, eşzamanlılık bakış açısı pratisyenler tarafından fazla ilgi görmemiştir; (ii) mantıksal bileşenlerin tasarımında en çok tercih edilen yapısal birim harici arayüzler olurken, en az tercih edilen ise içsel hesaplama birimi olmuştur; (iii) en çok tercih edilen mantıksal konektör tipi asenkron event konektörleri olarak belirlenmiştir; (iv) kompleks konektör tipleri (adaptör, dağıtıcı, arabulucu gibi) pek ilgi görmemektedir; (v) yazılım mimarilerini değişik bakış açılarından modellemede en çok tercih edilen notasyonlar kutucuklar ve çizgiler notasyonu ile doğal diller (İngilizce gibi) olurken, yazılım mimarisi modelleme dilleri ve biçimsel diller pek kullanılmamaktadır; (vi) yazılım sistemlerinin farklı bakış açıları kullanarak tasarlamada pratisyenlerin en büyük motivasyonu farklı tasarım kararlarının dokümantasyonu ve iletişimi olarak belirlenmiştir; (vii) bileşenlerin etkileşim davranışlarının tasarımı bir hayli ilgi görmektedir; (viii) değişik bakış açılarındaki modellerin birbirleri arasındaki ilişkilerinin tasarımının, modelleme notasyonlarının eksikliklerinden dolayı her zaman başarılamadığı gözlemlenmiştir; ve son olarak, (ix) pratisyenlerin sistemlerinin davranışsal tasarımlarında en çok önem verdiği kalite özellikleri ölçeklenebilirlik, performans, ve güvenlik olarak gözlemlenirken, dağıtım tasarımları için ise ölçeklenebilirlik ve kullanılabilirlik özelliklerinin öne çıktığı gözlemlenmiştir.
Anahtar Kelimeler. Yazılım Mimarileri, mimari bakış açıları, anket, yazılım modelleme dilleri, pratisyenler
Mert Ozkaya Yeditepe University, Atasehir, Istanbul
mozkaya@cse.yeditepe.edu.tr Abstract. Architecture viewpoints promote separating software architectures into different viewpoints that each address the particular aspect of a software system. This paper discusses a survey conducted among 56 practitioners from 20 different countries who are involved in software development and aims at understanding their knowledge and experience about five important architectural viewpoints – i.e., logical, behaviour, concurrency, physical, and deployment. Some of the interesting survey results are as follows: (i) while the logical, behaviour, physical, and deployment viewpoints are widely used, the concurrency viewpoint is not so; (ii) the top-preferred structural unit for a logical component is the external interfaces and the least-preferred is the internal computation unit. (iii) the top-preferred simple connector type is the asynchronous events; (iv) the complex connectors (e.g., adaptor and arbitrator) are not as popular as simple connectors; (v) boxes and lines diagram and natural languages (e.g., English) are the top-preferred software modelling notations for each viewpoint considered, while architectural languages, and formal specification languages are never used by many; (vi) documenting design decisions and their communication is the main source of motivation for each viewpoint; (vii) the specifications of the interaction behaviours of components are highly desired by practitioners; (viii) mapping between different viewpoints cannot always be achieved due to the inadequate software modelling notations; and (ix) scalability, performance, and security are the top-considered quality properties for the behaviour viewpoint, while scalability and availability are the top-considered ones for the deployment viewpoint. 1
Software architecture is considered as the blueprint of a software system to be
built, in which the low-level details of the system are abstracted and the
highlevel important aspects that play key roles in meeting the functional and
nonfunctional requirements of the system are focused on [
However, the current literature does not really aid in understanding
practitioners’ perspectives towards different architecture viewpoints. Indeed, many
issues, such as the notations preferred by practitioners for different viewpoints,
practitioners’ expectations from modeling software architectures in different
viewpoints, practitioners’ main motivations of modeling in different viewpoints, still
remain ambiguous. Therefore, in this study, a survey has been conducted among
a set of practitioners from different industries to understand their knowledge and
experience about the architectural viewpoints. The survey focuses on the five key
architectural viewpoints that have been proposed by Taylor et al. [
The survey consists of 38 different questions, which have been determined after several iterations of reviews. Among the 38 questions, just 9 questions use single-choice answers. 2 of them provide numeric (i.e., integer) answers in which the participants are requested to choose one of the ranges of numbers (e.g., 0-10, 11-50, 51-100, and 100+). The rest of the 7 questions are essentially the yes/no questions. However, to maximise the precision of the survey results, those questions each provide a rating answer, which offers the following options: always (100%), much of the time ( 75%), often ( 50%), sometimes (<50%), and never (0%). The rest of the questions offer multiple-choice answers and allow practitioners to choose as many of the answers as they wish. Note that each multiple-choice answer also include a "free-text" area in which practitioners can type any answers that are not existing in the list of the multiple-choice answer.
The survey has been designed for the software industry and intended for the practitioners who hold software related positions such as software architect, designer, developer, software engineer, programmer, and software project manager. To reach as many practitioners as possible, the social media platforms have been tried initially, including facebook, linkedin, google and yahoo groups, and some popular software development forums (e.g., stack overflow). Also, the existing architectural languages that support the viewpoints considered in the survey have been searched and any scientists with industry background who contributed to the development of those languages have been contacted via e-mail. Moreover, the mailing lists of the widely-known computing societies (i.e., ACM and IEEE) have been used. Lastly, the author’s personal contacts working in software industry have been requested to participate in the survey too. So, the survey received 56 different responses from practitioners all over the world. 3
In this part, the answers given to the survey questions are analysed. To facilitate understandability, the answers of the questions are considered in six different sections: one for the profile questions and a separate section for each viewpoint considered (i.e., logical, physical deployment, behaviour, and concurrency). For each section, the answers given to each relevant question are discussed separately. 3.1
Practitioners country of work (Q1). The survey attracted practitioners from 20 different countries, given as follows: USA, Colombia, Austria, Latvia, Chile, Indonesia, Ukraine, Australia, Belgium, Finland, France, Germany, India, Portugal, Russia, Spain, Sweden, the Netherlands, Turkey, and UK. The top participating country is USA (22%), which is followed by Turkey (13%), UK (11%), and France (9%).
Practitioners’ highest academic degrees and university subjects (Q2 and Q3). 76% of the practitioners hold postgraduate degrees, where 47% hold MSc or MA degrees and 29% hold PhD degrees. 22% of the practitioners hold undergraduate BSc or BS degrees. Lastly, 2% of the practitioners hold college degrees. Many of the practitioners (63%) have studied the computer science/engineering subject. Concerning the rest of the practitioners, 9% of the practitioners have studied software engineering, 7% studied information technology, 6% studied electrical and electronics engineering, and the other subjects (e.g., physics, maths, history, and management) have been studied by 2-4%.
Practitioners’ job positions (Q4). The software architect position is the topselected one, held by 48% of the practitioners, which is followed by the software developer/programmer (29%) and consultant (29%) positions. The system engineer position (14%) and the high-level manager positions are held by 11-14% of the practitioners.
Practitioners’ years of experience on the software architecture modelling (Q5). More than half of the practitioners (52%) have more than 10 years of experience. 21% of the practitioners have 6-10 years of experience, 13% of the practitioners just have 2-5 years of experience, and 9% have less than 2 years of experience. Note that 5% of the practitioners do not have any experience on the architecture modelling at all. These practitioners with no experience are directed to submit the survey form without answering the rest of the survey questions. Practitioners’ work industries (Q6). IT and telecommunications is the top industry that is selected by 47% of the practitioners. This is followed by the finance and accounting (27%), automative and transportation (22%), government (20%), defense/military aviation (16%) and healthcare and biomedical (12%) industries. 8% of the practitioners work in the software outsourcing industry. Practitioners’ software project types (Q7). The top software project type developed by practitioners is the business applications software (63%), which is followed by the web applications (57%) and mobile applications (51%). The systems software, scientific/engineering applications, and safety-critical and mission-critical software have been selected by 27-35% of the practitioners. The cloud applications and telecommunications software are the least selected software project types. 3.2
The practitioners who model software architectures from the logical viewpoint (Q8). Practitioners frequently model their software architectures from the logical viewpoint. Indeed, 36% of the practitioners always (100%) do so, 31% of the practitioners do so much of the time (>=75%), and 13% do so often (>=50%). Just 12% of the practitioners sometimes (<50%) model their software architectures from the logical viewpoint. 8% of the practitioners never (0%) model their software architectures from the logical viewpoint.
The structural units preferred for the logical components (Q9). As shown in
Fig. 1, most of the practitioners (84%) consider components in terms of their
external interfaces for sending/receiving services. Half of the practitioners also
wish to specify composite components (i.e., the unit of configuration), which
may structurally be composed of some other component and connector instances.
Some practitioners (48%) wish to specify the component state descriptions for
purposes such as the behaviour specifications (i.e., how the services impact on
the state). Lastly, the internal computation unit for specifying the internal
behaviours of components has been shown the least interest, selected by 30% of
the practitioners.
The types of logical connectors preferred by practitioners (Q10). In this survey,
the connector types proposed by Mehta et al. [
Practitioners’ motivations for modeling software architectures from the logical viewpoint (Q14). Almost all the practitioners are motivated by the abilities of (i) documenting and communicating the component structures (91%) and (ii) decomposing a large and complex problem into manageable and understandable components (86%). Also, many practitioners (64%) are interested in (i) documenting and communicating the types of connectors for the component interactions and (ii) analysing the static aspects of systems (e.g., inconsistencies, incompatibilities, and incompleteness). Surprisingly, generating software code from the logical view specifications or the languages’ distinguishing features (e.g., large-view management, graphical support, and extensibility) are not among the popular reasons, chosen by 25-30% of the practitioners. 3.3
The practitioners who model software architectures from the behaviour viewpoint
(Q15). Half of the practitioners frequently (>=75%) model their software
architectures from the behaviour viewpoint (19% chose always and 33% chose much
of the time). 11% of the practitioners often (>=50%) do so and 25% of the
practitioners sometimes (<50%) do so. 12% of the practitioners never software
architectures from the behaviour viewpoint.
The component behavioural units preferred by practitioners (Q16, Q17). As
shown in Fig. 4, practitioners are most interested in specifying the interaction
behaviours of components (81%) and their external interface behaviours (72%).
63% of the practitioners are interested in specifying the internal behaviours of
components. Lastly, 53% of the practitioners are interested in considering the
non-functional requirements (e.g., performance, security, and reliability) as part
of their component behaviour specifications.
The non-functional properties that practitioners are interested in (Q18). As
shown in Fig. 5, scalability, performance, and security are the top-preferred
non-functional properties (70-76%), which are followed by the availability and
reliability properties (62-65%). However, schedulability is preferred by just 14%
of the practitioners.
The software modelling notations used by practitioners for modeling software
architectures from the behaviour viewpoint (Q19, Q20). As shown in Fig. 6, the
boxes and lines diagram are the top-used notation for specifying the behaviour
views of software architectures, which is followed by UML’s sequence diagram,
UML’s state diagram, and the natural languages (e.g., English). Surprisingly,
DSLs, BPMLs, formal specification languages, and ALs are the least-preferred
modelling notations by practitioners in specifying the behaviour views.
Fig. 7: The formal specification languages used by practitioners for formally
modeling software architectures from the behaviour viewpoint
The formal specification languages used by practitioners for formally modeling
software architectures from the behaviour viewpoint (Q21). While most of the
practitioners never use formal specification languages as revealed in the previous
questions, a few of those stated that they use some formal notations. These
are Petri nets [
The architectural languages used by practitioners for modeling software
architectures from the behaviour viewpoint (Q22). Only a few number of practitioners
stated that they frequently use the ALs for modeling the software architectures
from the behaviour viewpoint. So, AADL is practitioners’ top choice, followed
by the Rapide [
Practitioners’ motivations for modeling software architectures from the behaviour viewpoint (Q23). Documenting and communicating the high-level system behaviours has been selected by almost all the practitioners (90%). The capabilitiy of making the optimal design decisions about the component behaviours and interactions is also found motivating by more than half of the practitioners (55%). Some practitioners (30-40%) stated that they are motivated by the abilities of (i) specifying the non-functional properties for the component behaviours and interactions and (ii) utilising from the modelling languages’ capabilities (e.g., precision, complex view management, extensibility, etc.). However, most practitioners do not see the generation of software code and the exhaustive (i.e., formal) analysis as the motivating reasons for the behaviour viewpoint modeling. 3.4
The practitioners who use the concurrency viewpoint (Q24) Most of the
practitioners do not model their software architectures from the concurrency
viewpoint. Indeed, while 38% sometimes (<50%) do so, another 38% never do so
really. Note that just 8% of the practitioners always model software
architectures from the concurrency viewpoint.
The software modelling notations used by practitioners for modeling software
architectures from the concurrency viewpoint (Q25, Q26). As shown in Fig. 8,
the boxes and lines diagram is the top preferred notation, followed by the natural
languages (e.g., English). A few practitioners use their own (in-house) DSLs for
modeling software architectures from the concurrency viewpoint. ALs, BPMLs,
DSLs, formal specification languages, and UML extensions are rarely used.
The formal specification languages used by practitioners for formally modeling
software architectures from the concurrency viewpoint (Q27). As indicated in
the previous question, the formal specification languages are rarely used for the
concurrency viewpoint modeling, Fig. 9 shows the formal languages used by a
few practitioners. So apparently, Petri nets, JML, and CSP that are shown in
Fig. 9 are preferred relatively more than any other languages by the practitioners
who use formal languages (20-30%). Some of those practitioners also stated that
they use some other formal languages that include Event-B [
The architectural languages used by practitioners for formally modeling software architectures from the concurrency viewpoint (Q28) Like the formal specification languages, a few practitioners stated that they use ALs for modeling software architectures from the concurrency viewpoint. Among the four popular ALs considered for modeling concurrency (Darwin, Rapide, AADL, and Wright), Darwin seems to be the top popular AL among practitioners. Some participants stated that they use their own ALs that they developed (indicated as other ). The software modelling notation(s) used for mapping the logical components into the concurrency components (Q29). Most of the practitioners (85%) who model software architectures from the concurrency viewpoint are also interested in mapping their logical components to the concurrency components. Those practitioners mainly prefer the natural languages (e.g., English) and simple boxes and lines diagram. A few practitioners prefer the software modelling languages, such as the ALs, BPMLs, DSLs, and UML’s extensions.
Practitioners’ motivations for modeling software architectures from the concurrency viewpoint (Q30). Almost all the practitioners (81%) are motivated by the ability for documenting and communicating the concurrency issues of their software systems. Many practitioners (59%) wish to specify the design decisions for avoiding the concurrency issues such as deadlock, livelock, and race-conditions. Some (30-37%) wish to meet the domain requirements of their concurrent systems. Surprisingly, only a few practitioners (22-26%) find the formal analysis of the concurrent specifications and the mapping between the logical and concurrent components as motivating. 3.5
The practitioners who use the physical and deployment viewpoints (Q31). More
than half of the practitioners (52%) frequently model their software architectures
from the physical and deployment viewpoints (i.e., always or much of the time).
While 16% of the practitioners often (>=50) do so, 22% of the practitioners
sometimes (<50) do so. Lastly, 10% of the practitioners never model software
architectures from the physical and deployment viewpoints.
The software modelling notations used by practitioners for modeling software
architectures from the physical and deployment viewpoints (Q32, Q33). As shown
in Fig. 10, the boxes and lines diagram is the top-preferred notation, which is
followed by the natural languages (e.g., English) and UML. The ALs, BPMLs,
and DSLs, SysML are never used by most of the practitioners for the physical
and deployment viewpoint modeling. Lastly, some of the practitioners stated
that they use their own DSLs, and some use the UAF standard [
The non-functional quality properties that practitioners consider for their deployment viewpoint modeling (Q35). According to the survey results, 84% of the practitioners who model software architectures from the physical & deployment viewpoints also consider documenting the non-functional quality properties that can then be used for analysing the deployment architectures. Among the four non-functional properties considered (i.e., availability, performance, scalability, and security), the availability (e.g., load balancing, redundancy, and failure situations) and scalability (e.g., the resource capacity for larger systems) properties are shown the greatest interest (79%). 67-69% of the practitioners consider the security (e.g., authentication and secure data transmission) and performance (e.g., the number of CPU and memory estimates) properties. Note that a few practitioners have chosen some other quality properties, i.e., maintainability, developer & operations cooperation, and regulatory compliance. The software modelling notation(s) that practitioners use for mapping the logical components into the physical components (Q36). The survey results reveal that 80% of the practitioners who model their software architectures from the physical & deployment viewpoints wish to map the logical components into the physical components. The simple boxes and lines diagram (53%) and natural languages (50%) are the top-popular techniques, followed by UML (40%). The rest of the software modelling notations (i.e., ALs, UML’s extensions, SysML, BPML, and DSLs) are shown a lack of interest, which are used by 10-15% of practitioners. The software modelling notation(s) that practitioners use for mapping the concurrent components into the physical components (Q37). According to the survey results, 60% of the practitioners who specify the physical & deployment views are interesting in mapping the concurrent components into the physical components. Practitioners prefer the simple boxes and lines diagram (42%) and natural languages (45%), and UML (34%), as is the case for the mapping between the logical and physical components discussed in Section 3.5.
Practitioners’ motivations for modeling software architectures from the physical and deployment viewpoints (Q38). According to the results, most of the practitioners (86%) are motivated by documenting and communicating their software systems’ physical components and their physical communications motivates them. 68% of the practitioners are motivated by the ability of analysing the deployment view specifications for quality properties. More than half of the practitioners (54%) are interested in mapping between the logical/concurrency views and physical views. Lastly, the modelling languages with useful capabilities (e.g., graphical support, formal analysis, tool support, etc.) and generating executable software code are shown a lack of interest by practitioners (14-19%). 4
The author has previously conducted some similar surveys on practitioners.
However, none of them considered the architectural viewpoints from practitioners’
perspectives. In [
May [
In this study, a survey has been conducted on understanding practitioners’ knowledge and experience about the logical, behaviour, concurrency, physical and deployment viewpoints. While the logical, behaviour, physical, and deployment viewpoints are used by many practitioners, the concurrency viewpoint for the specifications of the concurrency issues are shown a lack of interest by practitioners. For each viewpoint considered, practitioners stated that documenting the design decisions and their communications with other stakeholders are their main source of motivation. Also, practitioners prefer the boxes and lines diagram and natural languages (e.g., English) for each viewpoint considered. However, these notations do not offer any concrete syntax and semantics; so, the specifications may not be processed for purposes such as analysis and code generation.
Concerning the logical viewpoint, most practitioners view the logical
components structurally as the composition of external interfaces. Practitioners are
not so keen to specify the internal computations that are mainly concerned with
any internal actions operated on the component state. Practitioners are highly
interested in the event connectors, which may receive the asynchronous events
generated by a component and send it to all listening components. Complex
connectors such as arbitrators and distributors are rarely considered by
practitioners. This may be due to the lack of modeling languages that allow for
specifying complex connectors. Indeed, the event connectors are highly
popular among the architecture modeling languages [
In the future, the survey results are aimed to be used for the proposal of a novel architecture description language that supports the logical, behaviour, concurrency, physical, and deployment viewpoints in a way which addresses the needs of practitioners determined from the survey.