Relevant bibliographies by topics / Software architecture

Contents

  1. Journal articles
  2. Dissertations / Theses
  3. Books
  4. Book chapters
  5. Conference papers
  6. Reports

Academic literature on the topic 'Software architecture'

Author: Grafiati
Published: 4 June 2021
Last updated: 9 June 2025

Create a spot-on reference in APA, MLA, Chicago, Harvard, and other styles

Select a source type:

Consult the lists of relevant articles, books, theses, conference reports, and other scholarly sources on the topic 'Software architecture.'

Next to every source in the list of references, there is an 'Add to bibliography' button. Press on it, and we will generate automatically the bibliographic reference to the chosen work in the citation style you need: APA, MLA, Harvard, Chicago, Vancouver, etc.

You can also download the full text of the academic publication as pdf and read online its abstract whenever available in the metadata.

Journal articles on the topic "Software architecture"

1

Sahlabadi, Mahdi, Ravie Chandren Muniyandi, Zarina Shukur, and Faizan Qamar. "Lightweight Software Architecture Evaluation for Industry: A Comprehensive Review." Sensors 22, no. 3 (February 7, 2022): 1252. http://dx.doi.org/10.3390/s22031252.

Full text
Abstract:
Processes for evaluating software architecture (SA) help to investigate problems and potential risks in SA. It is derived from many studies that proposed a plethora of systematic SA evaluation methods, while industrial practitioners currently refrain from applying them since they are heavyweight. Nowadays, heterogeneous software architectures are organized based on the new infrastructure. Hardware and associated software allow different systems, such as embedded, sensor-based, modern AI, and cloud-based systems, to cooperate efficiently. It brings more complexities to SA evaluation. Alternatively, lightweight architectural evaluation methods have been proposed to satisfy the practitioner’s concerns, but practitioners still do not adopt these methods. This study employs a systematic literature review with a text analysis of SA’s definitions to propose a comparison framework for SA. It identifies lightweight features and factors to improve the architectural evaluation methods among industrial practitioners. The features are determined based on the practitioner’s concerns by analyzing the architecture’s definitions from stakeholders and reviewing architectural evaluation methods. The lightweight factors are acquired by studying the five most commonly used lightweight methods and the Architecture-based Tradeoff Analysis Method (ATAM), the most well-known heavyweight method. Subsequently, the research addresses these features and factors.
APA, Harvard, Vancouver, ISO, and other styles
2

WOODSIDE, C. M. "SOFTWARE RESOURCE ARCHITECTURE." International Journal of Software Engineering and Knowledge Engineering 11, no. 04 (August 2001): 407–29. http://dx.doi.org/10.1142/s0218194001000608.

Full text
Abstract:
Performance is determined by a system's resources and its workload. Some of the resources are software resources which are an aspect of the software architecture; some of them are even created by the software behaviour. This paper describes software resources and resource architecture, and shows how resource architecture can be determined from software architecture and behaviour. The resource architecture is distinct from views of software architecture which describe software components, but it is related to the so-called "execution view" of architecture. The paper considers how resource architecture emerges during design, the relationship of software and hardware resources, some classes of resource architecture, and what they can tell us about system performance. Other uses of resource architecture are, to analyze deadlocks, to understand special software architectures developed for demanding situations, and to analyze how subsystems fit together when they share resources. Resource architecture can be described using description languages (ADLs) developed for software architecture.
APA, Harvard, Vancouver, ISO, and other styles
3

Abuseta, Yousef. "Towards a Generic Software Architecture for IoT Systems." International Journal of Software Engineering & Applications 15, no. 6 (November 28, 2024): 01–16. https://doi.org/10.5121/ijsea.2024.15601.

Full text
Abstract:
The complexity of IoT, owing to the inherent distributed and dynamic nature of such systems, brings more challenges to the software development process. A vast number of devices with different communication protocols and data formats is involved and needs to be connected and exchange data with each other in a seamless manner. Traditional software architectures fall short of addressing the requirements of IoT systems and, therefore, a new approach to software architecture is required. This paper presents an attempt to lay out the foundation for a quality attribute driven software architecture for the development of IoT systems. This architecture accommodates the appropriate architectural styles and design patterns necessary for the development of a robust IoT system. These include edge computing, microservices and event driven architectures. The proposed architecture treats IoT systems as autonomic systems which require a closed control loop to regulate and orchestrate the operational aspect of the IoT system.
APA, Harvard, Vancouver, ISO, and other styles
4

Abd Elkareem, Noha, Mazen Selim, and Ahmed Shalaby. "Software-Defined Metaverse (SDM) Architecture." Journal of Metaverse 4, no. 2 (November 25, 2024): 146–56. http://dx.doi.org/10.57019/jmv.1541821.

Full text
Abstract:
The metaverse, a vast virtual shared space that integrates enhanced physical reality with persistent virtual environments, has the potential to revolutionize digital interaction by providing deeply immersive and interactive experiences. Leveraging cutting-edge technologies such as virtual reality (VR), augmented reality (AR), blockchain, artificial intelligence (AI), and cloud computing, the metaverse aims to harmonize the physical and digital worlds. However, existing metaverse architectures face significant challenges related to scalability, security, and efficiency. This paper introduces a novel Software-Defined Metaverse (SDM) Architecture, which uniquely addresses these challenges through a three-layered structure: the Application Layer, Control Layer, and Physical Layer. These layers are interconnected via standardized APIs, enabling efficient communication and data exchange. The architecture’s innovative centralization of control within the Control Layer not only enhances resource management but also significantly improves performance, scalability, and user experience. The modular design of the SDM Architecture facilitates seamless integration with emerging technologies, ensuring adaptability and long-term sustainability. By addressing critical technical hurdles and providing a robust, scalable framework, this work lays a strong foundation for future developments in the evolving digital landscape, positioning the SDM Architecture as a key enabler for the next generation of digital experiences.
APA, Harvard, Vancouver, ISO, and other styles
5

Medvidovic, Nenad, Eric M. Dashofy, and Richard N. Taylor. "The Role of Middleware in Architecture-Based Software Development." International Journal of Software Engineering and Knowledge Engineering 13, no. 04 (August 2003): 367–93. http://dx.doi.org/10.1142/s0218194003001330.

Full text
Abstract:
Software architectures promote development focused on modular functional building blocks (components), their interconnections (configurations), and their interactions (connectors). Since architecture-level components often contain complex functionality, it is reasonable to expect that their interactions will be complex as well. Middleware technologies such as CORBA, COM, and RMI provide a set of predefined services for enabling component composition and interaction. However, the potential role of such services in the implementations of software architectures is not well understood. In practice, middleware can resolve various types of component heterogeneity — across platform and language boundaries, for instance — but also can induce unwanted architectural constraints on application development. We present an approach in which components communicate through architecture-level software connectors that are implemented using middleware. This approach preserves the properties of the architecture-level connectors while leveraging the beneficial capabilities of the underlying middleware. We have implemented this approach in the context of a component- and message-based architectural style called C2 and demonstrated its utility in the context of several diverse applications. We argue that our approach provides a systematic and reasonable way to bridge the gap between architecture-level connectors and implementation-level middleware packages.
APA, Harvard, Vancouver, ISO, and other styles
6

Ulichev, Oleksandr, Oleksandr Dorenskyi, and Victor Kulahin. "Innovative Solutions and Benefits of Microservice Architecture for Software Products." Central Ukrainian Scientific Bulletin. Technical Sciences 1, no. 10(41) (2024): 16–29. https://doi.org/10.32515/2664-262x.2024.10(41).16-29.

Full text
Abstract:
The rapid advancement of technology and increasing market competition compel businesses to adapt swiftly by implementing new features and services to meet user demands. Traditional monolithic software architectures often hinder this agility due to challenges in scalability and maintenance. This article aims to analyze microservice architecture to solve these challenges, exploring its historical development, current trends, practical implementation aspects, and comparison with alternative architectural styles such as modulith architecture. The study examines the limitations of monolithic architectures in handling growing complexity and scaling requirements. It explores the emergence of microservice architecture, highlighting core characteristics like independent services, decentralized data management, and autonomous deployment. The evolution influenced by agile methodologies and DevOps practices is discussed. A comparative analysis with other architectural styles—including monolithic, service-oriented, modular monolithic, and serverless architectures—identifies contexts where microservices are most beneficial. The research reviews essential tools and technologies for implementing microservices, such as Docker for containerization, Kubernetes for orchestration, and service meshes like Istio and Linkerd. Practical cases from industry leaders like Netflix and Amazon illustrate successful adoption and the challenges faced during implementation. Findings indicate that while microservice architecture offers significant scalability, flexibility, and rapid deployment advantages, it also introduces complexities related to distributed system management and security. The study emphasizes the importance of adopting best practices and standards, such as those promoted by the Cloud Native Computing Foundation and utilizing modern tools to mitigate these challenges. For organizations where full microservices adoption may be impractical, modulith architecture is a viable alternative that combines modularity with deployment simplicity. The article concludes that the choice of architecture should be carefully aligned with the project's specific needs, resources, and long-term strategic goals.
APA, Harvard, Vancouver, ISO, and other styles
7

McGregor, John D. "Software Architecture." Journal of Object Technology 3, no. 5 (2004): 65. http://dx.doi.org/10.5381/jot.2004.3.5.c7.

Full text
APA, Harvard, Vancouver, ISO, and other styles
8

Anderson, Bruce, Mary Shaw, Larry Best, and Kent Beck. "Software architecture." ACM SIGPLAN Notices 28, no. 10 (October 1993): 356–59. http://dx.doi.org/10.1145/167962.165922.

Full text
APA, Harvard, Vancouver, ISO, and other styles
9

Ponnala Gangadhar Adepu, Ramesh. "Modeling Software Architecture with UML." International Journal of Science and Research (IJSR) 1, no. 3 (March 5, 2012): 21–26. http://dx.doi.org/10.21275/ijsr12120316.

Full text
APA, Harvard, Vancouver, ISO, and other styles
10

Roško, Zdravko. "Business Applications Architecture Model Based on Software Product Line Approach." Research Papers Faculty of Materials Science and Technology Slovak University of Technology 21, Special-Issue (June 1, 2013): 90–97. http://dx.doi.org/10.2478/rput-2013-0015.

Full text
Abstract:
Abstract Software product line architecture is one of the most important artifacts defined at the early stage of a product line development process. Since the rest of the products are developed based on the initial product line architecture, it is of high importance to ensure the architecture stability by enabling the software’s evolution possibilities. Industrial evidence shows that companies spend more resources on maintaining and evolving their architecture and products than on the initial development of them. Hence, there is a need for flexible software architecture that stays stable as the requirements evolve. In this paper we propose a structural model, some architecture quality metrics, case-based reasoning methodology to predict the architectural stability and a feature model for business applications. The goal of the proposed architecture model is to develop a framework for business applications development and evaluating the stability of product line architectures in the face of changes in requirements.
APA, Harvard, Vancouver, ISO, and other styles
More sources

Dissertations / Theses on the topic "Software architecture"

1

Bahtiyar, Muhammed Yasin. "Software Architecture Checker." Thesis, Växjö University, School of Mathematics and Systems Engineering, 2008. http://urn.kb.se/resolve?urn=urn:nbn:se:vxu:diva-2294.

Full text
Abstract:
<p>By the increasing needs of software industry, software systems became more complex constructions than ever before. As a result of increasing complexity in software systems, functional decomposition of these systems gains the status of the most important aspect in the software development process. Dividing problems to sub-problems and producing specific solutions for divided parts makes it easier to solve the main problem.</p><p>Component Based Software Engineering is a way of developing software systems that consists of logically or functionally decomposed components which integrated to each other by the help of well-defined interfaces. CBSE relies on architectural design of a software system.</p><p>Planning phase and implementation of a software project may differ time to time. Because of the complexity of software systems, solving specific problems may affect the architecture of the whole system.</p><p>In spite of sophisticated software engineering processes and CASE tools there is still a large gap between the planned and implemented architecture of software systems. Finding deviations from architecture in source code is a non-trivial task requiring tool support.</p><p>Since, matching operation of designed software architecture and implemented software architecture needs to check design documents against implementation code. This manual checking operation is nearly impossible for major software systems. Software Architecture Checker provides a great approach to check the architecture of any software system.</p><p>This bachelor thesis examines the approach behind the Software Architecture Checker.</p>
APA, Harvard, Vancouver, ISO, and other styles
2

Mårtensson, Frans, and Per Jönsson. "Software Architecture Simulation." Thesis, Blekinge Tekniska Högskola, Institutionen för programvaruteknik och datavetenskap, 2002. http://urn.kb.se/resolve?urn=urn:nbn:se:bth-4087.

Full text
Abstract:
A software architecture is one of the first steps towards a software system. A software architecture can be designed in different ways. During the design phase, it is important to select the most suitable design of the architecture, in order to create a good foundation for the system. The selection process is performed by evaluating architecture alternatives against each other. We investigate the use of continuous simulation of a software architecture as a support tool for architecture evaluation. For this purpose, we study a software architecture of an existing software system in an experiment, where we create a model of it using a tool for continuous simulation, and simulate the model. Based on the results from the simulation, we conclude that the system is too complex to be modeled for continuous simulation. Problems we identify are that we need discrete functionality to be able to correctly simulate the system, and that it is very time-consuming to develop a model for evaluation purposes. Thus, we find that continuous simulation is not appropriate for evaluating a software architecture, but that the modeling process is a valuable tool for increasing knowledge and understanding about an architecture.
APA, Harvard, Vancouver, ISO, and other styles
3

Barnes, Jeffrey M. "Software Architecture Evolution." Research Showcase @ CMU, 2013. http://repository.cmu.edu/dissertations/291.

Full text
Abstract:
Many software systems eventually undergo changes to their basic architectural structure. Such changes may be prompted by new feature requests, new quality attribute requirements, changing technology, or other reasons. Whatever the causes, architecture evolution is commonplace in real-world software projects. Today’s software architects, however, have few techniques to help them plan such evolution. In particular, they have little assistance in planning alternatives, making trade-offs among these different alternatives, or applying best practices for particular domains. To address this, we have developed an approach for assisting architects in planning and reasoning about software architecture evolution. Our approach is based on modeling and analyzing potential evolution paths that represent different ways of evolving the system. We represent an evolution path as a sequence of transitional architectural states leading from the initial architecture to the target architecture, along with evolution operators that characterize the transitions among these states. We support analysis of evolution paths through the definition and application of constraints that express rules governing the evolution of the systemand evaluation functions that assess path quality. Finally, a set of these modeling elements may be grouped together into an evolution style that encapsulates a body of knowledge relevant to a particular domain of architecture evolution. We evaluate this approach in three ways. First, we evaluate its applicability to real-world architecture evolution projects. This is accomplished through case studies of two very different software organizations. Second, we undertake a formal evaluation of the computational complexity of verifying evolution constraints. Finally, we evaluate the implementability of the approach based on our experiences developing prototype tools for software architecture evolution.
APA, Harvard, Vancouver, ISO, and other styles
4

Hatch, Andrew. "Software architecture visualisation." Thesis, Durham University, 2004. http://etheses.dur.ac.uk/3040/.

Full text
Abstract:
Tracing the history of software engineering reveals a series of abstractions. In early days, software engineers would construct software using machine code. As time progressed, software engineers and computer scientists developed higher levels of abstraction in order to provide tools to assist in building larger software systems. This has resulted in high-level languages, modelling languages, design patterns, and software architecture. Software architecture has been recognised as an important tool for designing and building software. Some research takes the view that the success or failure of a software development project depends heavily on the quality of the software architecture. For any software system, there are a number of individuals who have some interest in the architecture. These stakeholders have differing requirements of the software architecture depending on the role that they take. Stakeholders include the architects, designers, developers and also the sales, services and support teams and even the customer for the software. Communication and understanding of the architecture is essential in ensuring that each stakeholder can play their role during the design, development and deployment of that software system. Software visualisation has traditionally been focused on aiding the understanding of software systems by those who perform development and maintenance tasks on that software. In supporting developers and maintainers, software visualisation has been largely concerned with representing static and dynamic aspects of software at the code level. Typically, a software visualisation will represent control flow, classes, objects, import relations and other such low level abstractions of the software. This research identifies the fundamental issues concerning software architecture visualisation. It does this by identifying the practical use of software architecture in the real world, and considers the application of software visualisation techniques to the visualisation of software architecture. The aim of this research is to explore the ways in which software architecture visualisation can assist in the tasks undertaken by the differing stakeholders in a software system and its architecture. A prototype tool, named ArchVis, has been developed to enable the exploration of some of the fundamental issues in software architecture visualisation. ArchVis is a new approach to software architecture visualisation that is capable of utilising multiple sources and representations of architecture in order to generate multiple views of software architecture. The mechanism by which views are generated means that they can be more relevant to a wider collection of stakeholders in that architecture. During evaluation ArchVis demonstrates the capability of utilising a number of data sources in order to produce architecture visualisations. Arch Vis' view model is capable of generating the necessary views for architecture stakeholders and those stakeholders can navigate through the views and data in order to obtain relevant information. The results of evaluating ArchVis using a framework and scenarios demonstrate that the majority of the objectives of this research have been achieved.
APA, Harvard, Vancouver, ISO, and other styles
5

Pei, Breivold Hongyu. "Software Architecture Evolution and Software Evolvability." Licentiate thesis, Mälardalen University, School of Innovation, Design and Engineering, 2009. http://urn.kb.se/resolve?urn=urn:nbn:se:mdh:diva-4540.

Full text
Abstract:
<p>Software is characterized by inevitable changes and increasing complexity, which in turn may lead to huge costs unless rigorously taking into account change accommodations. This is in particular true for long-lived systems. For such systems, there is a need to address evolvability explicitly during the entire lifecycle, carry out software evolution efficiently and reliably, and prolong the productive lifetime of the software systems.</p><p>In this thesis, we study evolution of software architecture and investigate ways to support this evolution.           The central theme of the thesis is how to analyze software evolvability, i.e. a system’s ability to easily accommodate changes. We focus on several particular aspects: (i) what software characteristics are necessary to constitute an evolvable software system; (ii) how to assess evolvability in a systematic manner; (iii) what impacts need to be considered given a certain change stimulus that results in potential requirements the software architecture needs to adapt to, e.g. ever-changing business requirements and advances of technology.</p><p>To improve the capability in being able to on forehand understand and analyze systematically the impact of a change stimulus, we introduce a software evolvability model, in which subcharacteristics of software evolvability and corresponding measuring attributes are identified. In addition, a further study of one particular measuring attribute, i.e. modularity, is performed through a dependency analysis case study.</p><p>We introduce a method for analyzing software evolvability at the architecture level. This is to ensure that the implications of the potential improvement strategies and evolution path of the software architecture are analyzed with respect to the evolvability subcharacteristics. This method is proposed and piloted in an industrial setting.</p><p>The fact that change stimuli come from both technical and business perspectives spawns two aspects that we also look into in this research, i.e. to respectively investigate the impacts of technology-type and business-type of change stimuli.</p>
APA, Harvard, Vancouver, ISO, and other styles
6

Svahnberg, Mikael. "Supporting Software Architecture Evolution." Doctoral thesis, Ronneby : Blekinge Institute of Technology, 2003. http://urn.kb.se/resolve?urn=urn:nbn:se:bth-00232.

Full text
Abstract:
Today it is more a rule than an exception that software systems have a lifecycle of more than several years. Hence, software evolution is inevitable. During the life span of a software system the domain in which the system is working evolves and changes. This causes changes to the software system, and the software system may also be evolved to satisfy new markets. The ability to evolve gracefully, and thus the long-term success of a software system, is to a large extent governed by its software architecture and the ability of the software architecture to fulfil requirements on quality attributes and to adapt to evolving requirements. In this thesis we study evolution of software architectures and what can be done to support this evolution. We focus on three particular aspects of evolution support: how to ensure that the correct blend of quality attributes is met (architecture selection), the technical means available for supporting changes in the software system (variability), and what types of changes that are likely to occur during evolution (categories of evolution). We introduce a method for architecture evaluation and selection that focus on ensuring that the selected software architecture is the architecture candidate with the most potential for fulfilling a particular blend of quality attributes. The method is based on quantification of expert opinions and focused discussions where these expert opinions differ. The architecture evaluation and selection method is studied in both an academic and in an industry setting. We also introduce a taxonomy of techniques for realising variability in a software system and study how the techniques in this taxonomy are applied in different evolution situations. The taxonomy is based on several industry case studies. Two industry cases are studied in further detail and the evolution of these systems are followed over a number of releases and generations. During this evolution it is shown how variability mechanisms are used to also support evolution, and that there are typical cases of evolution that a software system can be prepared to cope with. The contribution of this thesis is that it increases the understanding of how evolution occurs in a software system, how to create software that is flexible enough to support evolution and how to evaluate and select a software architecture that meets a particular blend of quality attributes. Together this ensures that a software system is based on a software architecture that fits the current quality requirements and that is flexible in the right places so that it is able to evolve gracefully.
APA, Harvard, Vancouver, ISO, and other styles
7

Ström, David. "Purposes of Software Architecture Design." Thesis, Blekinge Tekniska Högskola, Avdelningen för programvarusystem, 2005. http://urn.kb.se/resolve?urn=urn:nbn:se:bth-2830.

Full text
Abstract:
Software architecture design as an engineering field has evolved greatly during the last 15 years, which is evident by the number of methods, styles, patterns, and guidelines available for its practitioners in industry. This paper takes a closer look at the purposes behind this field to reveal the level of discrepancy in pursued purposes between industrial practitioners and published methods for software architecture design. In our research surveys of architecture design methods and of purposes at a number of industrial practitioners resulted in two sets of purposes which were eventually compared and the level of discrepancy identified.<br>Mjukvarudesign är ett område inom mjukvaruindustrin som utvecklats omfattande under de senaste 15 åren, vilket synliggjorts av de nya metoder, designstilar, designmönster och paradigmer som gjorts tillgängliga för mjukvaruutvecklare idag. Den här uppsatsen gör en djupgranskning av syftena bakom detta arbetsområde för att upptäcka eventuella skillnader mellan de syften som framhålls av befintliga arkitekturmetoder och de syften som åtsträvas av utövare inom mjukvaruindustrin.
APA, Harvard, Vancouver, ISO, and other styles
8

Cunningham, Hamish. "Software architecture for language engineering." Thesis, University of Sheffield, 2000. http://ethos.bl.uk/OrderDetails.do?uin=uk.bl.ethos.324440.

Full text
APA, Harvard, Vancouver, ISO, and other styles
9

Wermelinger, Miguel Alexandre. "Specification of software architecture reconfiguration." Doctoral thesis, FCT - UNL, 1999. http://hdl.handle.net/10362/1137.

Full text
Abstract:
In the past years, Software Architecture has attracted increased attention by academia and industry as the unifying concept to structure the design of complex systems. One particular research area deals with the possibility of reconfiguring architectures to adapt the systems they describe to new requirements. Reconfiguration amounts to adding and removing components and connections, and may have to occur without stopping the execution of the system being reconfigured. This work contributes to the formal description of such a process. Taking as a premise that a single formalism hardly ever satisfies all requirements in every situation, we present three approaches, each one with its own assumptions about the systems it can be applied to and with different advantages and disadvantages. Each approach is based on work of other researchers and has the aesthetic concern of changing as little as possible the original formalism, keeping its spirit. The first approach shows how a given reconfiguration can be specified in the same manner as the system it is applied to and in a way to be efficiently executed. The second approach explores the Chemical Abstract Machine, a formalism for rewriting multisets of terms, to describe architectures, computations, and reconfigurations in a uniform way. The last approach uses a UNITY-like parallel programming design language to describe computations, represents architectures by diagrams in the sense of Category Theory, and specifies reconfigurations by graph transformation rules.<br>Association for Computing Machinery PRAXIS XXI 2/2.1/MAT/46/94 Fundação Calouste Gulbenkian PRAXIS XXI PCEX/P/MAT/46/96 PRAXIS XXI 2/2.1/ TIT/1662/95
APA, Harvard, Vancouver, ISO, and other styles
10

Väisänen, T. (Toni). "Applied software architecture on Graphingwiki." Bachelor's thesis, University of Oulu, 2017. http://urn.fi/URN:NBN:fi:oulu-201710042937.

Full text
Abstract:
Graphingwiki extends the wikiengine MoinMoin by providing tools for visualizing the interconnections between the wiki pages. The extension has been used for collaborative dependency mapping. Graphingwiki can be considered a legacy system, because there is no documentation available. This thesis focuses on applied software archeology to gain understanding on the implementation in order to support decision-making as regards to its further development. An overview of the system was mapped by using code execution tracing and by reading the code manually. Performance of the Graphingwiki graph generation process and the MoinMoin user creation and authentication methods were analyzed. The results show that the undermining factor of Graphingwiki’s performance was bitmap caching of the generated graphs and, in contrast, the user creation and authentication methods were both usable and extendable. In all these aspects, there is room for improvement. The results demonstrated that by bypassing the bitmap caching, the server response time could be improved up to 90%. The password complexity requirements of MoinMoin should be updated to conform to the OWASP guidelines. Further research is recommended to solve the needs of active users and to implement the graphing process more efficiently<br>Graphingwiki laajentaa MoinMoin-wikiohjelmistoa tarjoamalla työkalut wikisivuston yhteyksien visualisoimiseen. Sitä on käytetty riippuvuuksien kartoitukseen yhteistyömenetelmissä. Graphingwiki voidaan katsoa ”legacy”-järjestelmäksi, koska dokumentaatiota ei ole saatavilla. Tämän työn ensisijainen fokus on sovellettussa ohjelmistoarkeologiassa nykyisen implementaation ymmärtämiseksi tukemaan päätöksentekoa sen suhteen, kuinka jatkokehitystä tulisi lähestyä. Järjestelmän yleisnäkymä kartoitettiin käyttämällä lähdekoodin suorituksen jäljitystä ja lukien koodia manuaalisesti. Graphingwikin graafigeneroinnin suorituskyky ja MoinMoinin käyttäjän luomis- sekä autentikaatiomenetelmät analysoitiin. Tulokset osoittavat, että Graphingwikin suorituskykyä heikentävä tekijä on generoitujen graafikuvien tallentaminen välimuistiin, mutta MoinMoinin käyttäjän luomis- ja autentikaatiomenetelmät ovat sekä käyttökelpoisia ja laajennettavia. Kaikilta näiltä osa-alueilta löytyi parannettavaa. Näiden tuloksien perusteella tiedetään, että ohittamalla generoitujen kuvien tallentaminen välimuistiin serverin vasteaikaa voitaisiin parantaa jopa 90%. MoinMoinin salasanojen vaatimukset olisi hyvä päivittää vastaamaan OWASP:n suosituksia. Jatkotutkimus olisi suositeltavaa nykyisten käyttäjien tarpeiden selvittämiseksi ja visualisoinnin tehokkaammaksi toteuttamiseksi
APA, Harvard, Vancouver, ISO, and other styles
More sources

Books on the topic "Software architecture"

1

Biffl, Stefan, Elena Navarro, Welf Löwe, Marjan Sirjani, Raffaela Mirandola, and Danny Weyns, eds. Software Architecture. Cham: Springer International Publishing, 2021. http://dx.doi.org/10.1007/978-3-030-86044-8.

Full text
APA, Harvard, Vancouver, ISO, and other styles
2

Scandurra, Patrizia, Matthias Galster, Raffaela Mirandola, and Danny Weyns, eds. Software Architecture. Cham: Springer International Publishing, 2022. http://dx.doi.org/10.1007/978-3-031-15116-3.

Full text
APA, Harvard, Vancouver, ISO, and other styles
3

Gerostathopoulos, Ilias, Grace Lewis, Thais Batista, and Tomáš Bureš, eds. Software Architecture. Cham: Springer International Publishing, 2022. http://dx.doi.org/10.1007/978-3-031-16697-6.

Full text
APA, Harvard, Vancouver, ISO, and other styles
4

Drira, Khalil, ed. Software Architecture. Berlin, Heidelberg: Springer Berlin Heidelberg, 2013. http://dx.doi.org/10.1007/978-3-642-39031-9.

Full text
APA, Harvard, Vancouver, ISO, and other styles
5

Cuesta, Carlos E., David Garlan, and Jennifer Pérez, eds. Software Architecture. Cham: Springer International Publishing, 2018. http://dx.doi.org/10.1007/978-3-030-00761-4.

Full text
APA, Harvard, Vancouver, ISO, and other styles
6

Weyns, Danny, Raffaela Mirandola, and Ivica Crnkovic, eds. Software Architecture. Cham: Springer International Publishing, 2015. http://dx.doi.org/10.1007/978-3-319-23727-5.

Full text
APA, Harvard, Vancouver, ISO, and other styles
7

Lopes, Antónia, and Rogério de Lemos, eds. Software Architecture. Cham: Springer International Publishing, 2017. http://dx.doi.org/10.1007/978-3-319-65831-5.

Full text
APA, Harvard, Vancouver, ISO, and other styles
8

Crnkovic, Ivica, Volker Gruhn, and Matthias Book, eds. Software Architecture. Berlin, Heidelberg: Springer Berlin Heidelberg, 2011. http://dx.doi.org/10.1007/978-3-642-23798-0.

Full text
APA, Harvard, Vancouver, ISO, and other styles
9

Tekinerdogan, Bedir, Uwe Zdun, and Ali Babar, eds. Software Architecture. Cham: Springer International Publishing, 2016. http://dx.doi.org/10.1007/978-3-319-48992-6.

Full text
APA, Harvard, Vancouver, ISO, and other styles
10

Bures, Tomas, Laurence Duchien, and Paola Inverardi, eds. Software Architecture. Cham: Springer International Publishing, 2019. http://dx.doi.org/10.1007/978-3-030-29983-5.

Full text
APA, Harvard, Vancouver, ISO, and other styles
More sources

Book chapters on the topic "Software architecture"

1

Vogel, Oliver, Ingo Arnold, Arif Chughtai, and Timo Kehrer. "Architectures and Architecture Disciplines (WHAT)." In Software Architecture, 39–64. Berlin, Heidelberg: Springer Berlin Heidelberg, 2011. http://dx.doi.org/10.1007/978-3-642-19736-9_3.

Full text
APA, Harvard, Vancouver, ISO, and other styles
2

Gebhardt, Friedrich, Angi Voß, Wolfgang Gräther, and Barbara Schmidt-Belz. "Software Architecture." In Reasoning with Complex Cases, 195–211. Boston, MA: Springer US, 1997. http://dx.doi.org/10.1007/978-1-4615-6233-7_18.

Full text
APA, Harvard, Vancouver, ISO, and other styles
3

Doornbos, Richard, and Sjir van Loo. "Software Architecture." In From scientific instrument to industrial machine, 43–50. Dordrecht: Springer Netherlands, 2012. http://dx.doi.org/10.1007/978-94-007-4147-8_4.

Full text
APA, Harvard, Vancouver, ISO, and other styles
4

Dooley, John F. "Software Architecture." In Software Development, Design and Coding, 53–63. Berkeley, CA: Apress, 2017. http://dx.doi.org/10.1007/978-1-4842-3153-1_5.

Full text
APA, Harvard, Vancouver, ISO, and other styles
5

Budgen, David. "Software Architecture." In Software Design, 77–92. Third edition. | Boca Raton : CRC Press, 2021. | Series: Chapman & Hall/CRC innovations in software engineering: Chapman and Hall/CRC, 2020. http://dx.doi.org/10.1201/b21883-9.

Full text
APA, Harvard, Vancouver, ISO, and other styles
6

Jalote, Pankaj. "Software Architecture." In A Concise Introduction to Software Engineering, 1–26. London: Springer London, 2008. http://dx.doi.org/10.1007/978-1-84800-302-6_5.

Full text
APA, Harvard, Vancouver, ISO, and other styles
7

Dooley, John F., and Vera A. Kazakova. "Software Architecture." In Software Development, Design, and Coding, 145–60. Berkeley, CA: Apress, 2024. http://dx.doi.org/10.1007/979-8-8688-0285-0_7.

Full text
APA, Harvard, Vancouver, ISO, and other styles
8

Streekmann, Niels. "Software Architecture." In Clustering-Based Support for Software Architecture Restructuring, 9–22. Wiesbaden: Vieweg+Teubner Verlag, 2012. http://dx.doi.org/10.1007/978-3-8348-8675-0_2.

Full text
APA, Harvard, Vancouver, ISO, and other styles
9

Dooley, John. "Software Architecture." In Software Development and Professional Practice, 47–58. Berkeley, CA: Apress, 2011. http://dx.doi.org/10.1007/978-1-4302-3802-7_5.

Full text
APA, Harvard, Vancouver, ISO, and other styles
10

Laplante, Phillip A., and Mohamad Kassab. "Software Architecture." In What Every Engineer Should Know about Software Engineering, 91–112. 2nd ed. Boca Raton: CRC Press, 2022. http://dx.doi.org/10.1201/9781003218647-5.

Full text
APA, Harvard, Vancouver, ISO, and other styles

Conference papers on the topic "Software architecture"

1

Homay, Aydin, and Mario de Sousa. "Axiomatic Software Architecture." In 2025 IEEE 22nd International Conference on Software Architecture Companion (ICSA-C), 11–15. IEEE, 2025. https://doi.org/10.1109/icsa-c65153.2025.00008.

Full text
APA, Harvard, Vancouver, ISO, and other styles
2

Cavalcante, Everton, and Thais Batista. "Using Software Architecture Descriptions to Detect Architectural Smells at Design Time." In Congresso Ibero-Americano em Engenharia de Software. Sociedade Brasileira de Computação, 2023. http://dx.doi.org/10.5753/cibse.2023.24697.

Full text
Abstract:
Architectural smells are decisions made at the software architecture level, whether intentional or not, that may negatively impact the quality of a software system. In the literature, architectural smells are identified mainly by relying on the source code or other implementation artifacts. However, architectural smells could be detected at design time, even before employing implementation efforts and preventing them from being reflected at the system implementation. This research investigates how software architecture descriptions realized through architecture description languages (ADLs) can be used to identify architectural smells at design time. This work focuses on how architectural smells manifest and can be detected in SysADL, an ADL that allows describing both structure and behavior of software architectures using standardized diagrams from the OMG’s SysML language.
APA, Harvard, Vancouver, ISO, and other styles
3

E. U. Silva, Douglas, Roberto A. Bittencourt, and Rodrigo T. Calumby. "Clustering Similarity Measures for Architecture Recovery of Evolving Software." In VII Workshop on Software Visualization. Sociedade Brasileira de Computação - SBC, 2019. http://dx.doi.org/10.5753/vem.2019.7583.

Full text
Abstract:
Automated software architecture recovery of module views from source code is a challenging research issue. Different similarity measures are used to evaluate clustering algorithms in the software architecture recovery of module views. However, few studies seek to evaluate whether such measures accurately capture the similarities between two clusterings. This work presents an evaluation of six clustering similarity measures through the use of intrinsic quality and stability measures and the use of ground truth architectures proposed by developers. The results suggest that the MeCl metric is the most adequate to measure similarity in the context of comparison with ground truth models provided by developers. However, when the architectural models do not exist, the Purity metric shows the best results, as measured by the correlation with the intrinsic Silhouette coefficient.
APA, Harvard, Vancouver, ISO, and other styles
4

Garlan, David, and Mary Shaw. "Software architecture." In the 19th ACM SIGSOFT symposium and the 13th European conference. New York, New York, USA: ACM Press, 2011. http://dx.doi.org/10.1145/2025113.2025116.

Full text
APA, Harvard, Vancouver, ISO, and other styles
5

Taylor, Richard N. "Software architecture." In the 7th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering. New York, New York, USA: ACM Press, 2009. http://dx.doi.org/10.1145/1595696.1595754.

Full text
APA, Harvard, Vancouver, ISO, and other styles
6

Garlan, David. "Software architecture." In the conference. New York, New York, USA: ACM Press, 2000. http://dx.doi.org/10.1145/336512.336537.

Full text
APA, Harvard, Vancouver, ISO, and other styles
7

Anderson, Bruce, Mary Shaw, Larry Best, and Kent Beck. "Software architecture." In the eighth annual conference. New York, New York, USA: ACM Press, 1993. http://dx.doi.org/10.1145/165854.165922.

Full text
APA, Harvard, Vancouver, ISO, and other styles
8

Medvidovic, Nenad, and Richard N. Taylor. "Software architecture." In the 32nd ACM/IEEE International Conference. New York, New York, USA: ACM Press, 2010. http://dx.doi.org/10.1145/1810295.1810435.

Full text
APA, Harvard, Vancouver, ISO, and other styles
9

Sosa, Manuel E., Tyson Browning, and Ju¨rgen Mihm. "Studying the Dynamics of the Architecture of Software Products." In ASME 2007 International Design Engineering Technical Conferences and Computers and Information in Engineering Conference. ASMEDC, 2007. http://dx.doi.org/10.1115/detc2007-34761.

Full text
Abstract:
This paper reports on an exploratory study of how the architecture of a software product evolves over time. Because software is embedded in many of today’s complex products, and it is prone to relatively rapid change, it is instructive to study software architecture evolution for general insights into product design. We use metrics to capture the intrinsic complexity of software architectures as they evolve through successive generations (version releases). We introduce a set of product representations and metrics that take into account two important features used to manage the complexity in software products: layers and modules. We also capture organizational data associated with the product under development. We propose a three-step approach for the analysis and illustrate it using successive versions of an open source product, Ant. One of our findings is that software architectures seem to evolve in a non-linear manner similar to the S-shaped curve that characterizes technology evolution at the industry level. We also find several parallel patterns among architectural and organizational dynamics. Implications for research and practice are discussed.
APA, Harvard, Vancouver, ISO, and other styles
10

Masuda, Satoshi, Jon Hagar, Yasuharu Nishi, and Kazuhiro Suzuki. "Software Test Architecture Definition by Analogy with Software Architecture." In 2022 IEEE International Conference on Software Testing, Verification and Validation Workshops (ICSTW). IEEE, 2022. http://dx.doi.org/10.1109/icstw55395.2022.00050.

Full text
APA, Harvard, Vancouver, ISO, and other styles

Reports on the topic "Software architecture"

1

Khare, Rohit. Decentralized Software Architecture. Fort Belvoir, VA: Defense Technical Information Center, December 2002. http://dx.doi.org/10.21236/ada441133.

Full text
APA, Harvard, Vancouver, ISO, and other styles
2

Bachmann, Felix, Len Bass, Jeromy Carriere, Paul Clements, David Garlan, James Ivers, Robert Nord, and Reed Little. Software Architecture Documentation in Practice: Documenting Architectural Layers. Fort Belvoir, VA: Defense Technical Information Center, March 2000. http://dx.doi.org/10.21236/ada377988.

Full text
APA, Harvard, Vancouver, ISO, and other styles
3

Wood, William G., Mario Barbacci, Paul Clements, Steve Palmquist, and Huei-Wan Ang. DoD Architecture Framework and Software Architecture Workshop Report. Fort Belvoir, VA: Defense Technical Information Center, March 2003. http://dx.doi.org/10.21236/ada416453.

Full text
APA, Harvard, Vancouver, ISO, and other styles
4

Bachmann, Felix, Len Bass, Paul Clements, David Garlan, and James Ivers. Documenting Software Architecture: Documenting Behavior. Fort Belvoir, VA: Defense Technical Information Center, January 2002. http://dx.doi.org/10.21236/ada399792.

Full text
APA, Harvard, Vancouver, ISO, and other styles
5

Bachmann, Felix, Len Bass, Paul Clements, David Garlan, and James Ivers. Documenting Software Architecture: Documenting Interfaces. Fort Belvoir, VA: Defense Technical Information Center, June 2002. http://dx.doi.org/10.21236/ada403788.

Full text
APA, Harvard, Vancouver, ISO, and other styles
6

Hamilton, Jr, Murtagh John A., and Jeanne L. Enabling Interoperability Via Software Architecture. Fort Belvoir, VA: Defense Technical Information Center, January 2000. http://dx.doi.org/10.21236/ada458021.

Full text
APA, Harvard, Vancouver, ISO, and other styles
7

Clements, Paul C., and Linda M. Northrop. Software Architecture: An Executive Overview. Fort Belvoir, VA: Defense Technical Information Center, February 1996. http://dx.doi.org/10.21236/ada305470.

Full text
APA, Harvard, Vancouver, ISO, and other styles
8

Clements, Paul C. Coming Attractions in Software Architecture. Fort Belvoir, VA: Defense Technical Information Center, January 1996. http://dx.doi.org/10.21236/ada309156.

Full text
APA, Harvard, Vancouver, ISO, and other styles
9

Bass, Len, Bonnie E. John, and Jesse Kates. Achieving Usability Through Software Architecture. Fort Belvoir, VA: Defense Technical Information Center, March 2001. http://dx.doi.org/10.21236/ada387874.

Full text
APA, Harvard, Vancouver, ISO, and other styles
10

Auguston, Mikhail. Software Architecture Built from Behavior Models. Fort Belvoir, VA: Defense Technical Information Center, June 2009. http://dx.doi.org/10.21236/ada502640.

Full text
APA, Harvard, Vancouver, ISO, and other styles
You might also be interested in the extended bibliographies on the topic 'Software architecture' for particular source types:
Journal articles Dissertations / Theses Books
We offer discounts on all premium plans for authors whose works are included in thematic literature selections. Contact us to get a unique promo code!

To the bibliography