Definition Of Software Architecture Research Articles

Architecture-Driven Development of an Electronic Health Record Considering the SOAQM Quality Model

Service computing has been considered for many years a suitable solution to develop and integrate legacy systems. Considering the important role of services for integrating legacy systems in organizations, quality should be treated as a key issue. By observing previous works published in the literature, it is clear that there is a need for the development of a specific quality model for Service-Oriented Architecture based on the latest ISO/IEC 25010 standard. This article presents a SOA quality model, named SOAQM, multiple architecture views and design decisions for developing an electronic health record (EHR). Most often, quality aspects, architectural views and decisions are neglected during the EHR development, which leads to difficulties for future software maintenance. Even those studies which present the software architecture only describe one or two views, or even a multiple number of views in only one box diagram, which may be confusing for most stakeholders. The process proposed in this article to develop the EHR system includes definition of software architecture through architectural decisions, multiple views and UML and SoaML models. The set of architectural decisions defined to develop the EHR was guided by SOAQM. A technical evaluation was performed by a group of eight software specialists that analyzed the EHR process development through a technical report and then provided their opinions through questionnaires and interviews. As a result of this evaluation, the EHR development process guided by the SOAQM quality model is considered important as it regards quality attributes in software development since early stages.

Decision making in software architecture

Traditionally, software architecture is seen as the result of the software architecture design process, the solution, usually represented by a set of components and connectors. Recently, the why of the solution, the set of design decisions made by the software architect, is complementing or even replacing the solution-oriented definition of software architecture. This in turn leads to the study of the process of making these decisions. We outline some research directions that may help us understand and improve the software architecture design process.

Translating Semantic Networks to UML Class Diagrams

The high importance of a proper definition of software architecture is obvious, but this task is not easy, especially in large projects. The project scheme should be legibly structured and clearly visualized. To that aim, usually widespread UML class diagrams are used. However, this way is not flexible and clear enough at the initial state of the development, so there is a need of a more appropriate method. Semantic networks are not so commonly used to meet these demands. Nevertheless, this notation is a fairly suitable approach to building evolutionary computing system architectures. Also, this can be a good mediator for other formats. Moreover, the tools for that may become quite powerful and relevant.

Software architecture definition for on-demand cloud provisioning

Cloud computing is a promising paradigm for the provisioning of IT services. Cloud computing infrastructures, such as those offered by the RESERVOIR project, aim to facilitate the deployment, manag...

Pay me now or pay me more later.

Institutionalizing innovation is hard work. The status quo is known, the new world is not. Managers whose primary goal is immediate risk reduction are rightfully cautious about new techniques and strategies, but change is inevitable. I want to consider an example involving software architecture definition in this issue of Strategic Software Engineering and attempt to illustrate both the new technique and the issues that are raised by adopting it. I will offer some suggestions on easing the transition.

Describing software architecture styles using graph grammars

We believe that software architectures should provide an appropriate basis for the proof of properties of large software. This goal can be achieved through a clearcut separation between computation and communication and a formal definition of the interactions between individual components. We present a formalism for the definition of software architectures in terms of graphs. Nodes represent the individual agents and edges define their interconnection. Individual agents can communicate only along the links specified by the architecture. The dynamic evolution of an architecture is defined independently by a "coordinator". An architecture style is a class of architectures specified by a graph grammar. The class characterizes a set of architectures sharing a common communication pattern. The rules of the coordinator are statically checked to ensure that they preserve the constraints imposed by the architecture style.

Software architecture styles as graph grammars

We present a formalism for the definition of software architectures in terms of graphs. Nodes represent the individual agents and edges define their interconnection. Individual agents can communicate only along the links specified by the architecture. The dynamic evolution of the overall architecture is defined independently by a 'coordinator'. An architecture style is a class of architectures characterised by a graph grammar. The rules of the coordinator are statically checked to ensure that they preserve the constraints imposed by the architecture style.