The graphical user interface (GUI) could have a major impact on the successof an application. Like any other software component, the GUI is designedbefore being developed. The software design process usually starts with anabstract design that is illustrated via a modeling language and narrows downto more specific details during the process. However, there are not anymodeling languages that are explicitly focusing on designing the blueprint ofthe GUI. Developing a modeling language that is specialized in designing theskeleton of the graphical user interface could offer the software designers,architectures and clients the means of obtaining a better communication andunderstanding. Thus, developing a better product. In this report, thedevelopment of such a modeling language was made. The modeling languagecan illustrate the blueprint of the GUI. The development process was madeafter researching and finding the most suitable development procedures forour modeling language.

Cascading failures involve a failure in one system component that triggers failures in successive system components, potentially leading to system wide failures. While frequently used fault tolerant techniques can reduce the severity and the frequency of such failures, they continue to occur in practice. To better understand how failures cascade, we have conducted a qualitative analysis of 55 cascading failures, described in 26 publicly available incident reports. Through this analysis we have identified 16 types of cascading mechanisms (organized into eight categories) that capture the nature of the system interactions that contribute to cascading failures. We also discuss three themes based on the observation that the cascading failures we have analyzed occurred in one of three ways: a component being unable to tolerate a failure in another component, through the actions of support or automation systems as they respond to an initial failure, or during system recovery. We believe that the 16 cascading mechanisms we present and the three themes we discuss, provide important insights into some of the challenges associated with engineering a truly resilient and well-supported system.

This document is the masters thesis called refactoring of object oriented application. Goal of this document was to introduce the problem of refactoring and apply gained knowledge on real software project. Document is divided into six chapters. The first chapter is introduction, the term refactoring is defined there with a brief history. Next chapter explains basic principles of refactoring, advantages and disadvantages of using refactoring. The third chapter is called catalog of refactorings and describes common patterns of refactoring. Next two chapters describe .NET platform and tools, which support refactoring on this platform. Sixth chapter is about real application of refactoring. Final chapter is conclusion and summary.

The environmental and economic implications of the increase in Information and Communication Technology energy consumption have become a topic of research in energy efficiency. Most studies focus on the energy estimation and optimization of lower tiers of the hardware and software infrastructures. However, the software itself is an indirect driver of energy consumption, therefore, its energy implications can be to some extent controlled by the software design. Software design patterns belong to high-level software abstractions that represent solutions to common design problems. Since patterns define the structure and behavior of software components, their application may come at energy efficiency costs that are not obvious to the software developers. The existing body of knowledge on energy consumption of software design patterns contains a number of gaps, some of which are addressed within the scope of this thesis project. More specifically, we conducted a series of experiments on the estimation of energy consumption of Visitor and Observer/Listener patterns within the context of non-trivial data parsing in Python. Furthermore, we considered a Patternless alternative for the same task. Additionally, our measurements include runtime duration and memory consumption. The results show that the Visitor pattern led to the largest energy consumption, followed by Observer/Listener and finally the Patternless version. We found a strong relationship between runtime duration and energy consumption, thus coming to the conclusion that the longest-running pattern is the most energy-consuming one. The findings of the current study can be beneficial for Python software developers interested in the energy implications of software design patterns.

No description available.

Context: A software project’s success; involvinga larger group of individuals, relies on efficient teamcommunication. Part of efficient communication is avoidingmiscommunication, misunderstandings, and losingknowledge. These consequences of poor communication canlead to negative repercussions such as loss of time, money,and customer approval. Much effort has been put intocreating tools and systems to aid software engineers inretaining knowledge and decisions made during meetings,but many existing solutions require additional manualintervention on the part of software meeting participants.The objective of this thesis is to explore and develop a toolcalled Design Extractor (DE) which creates concisesummaries of design meetings from recorded voiceconversations. These summaries include both the designdecisions made during a meeting as well as the rationalebehind them. This thesis used readily available Pythonframeworks for machine learning to train two transformermodels based on DistilBert and Google’s BERT. Fine-tuningthese models with data sourcedfrom six different softwaredesign meetings found that the best base model wasDistilBert, which resulted in a fine-tuned model reporting anF1 score of 82.63%. This study created a simple Python tool,built upon many publicly available Python frameworks andthe fine-tuned transformer model, that takes in voicerecordings and outputs labeled sentence-label pairs that canbe used to quickly notate a design meeting. Short summariesare also provided by the tool through the use of pre-existingtext summarisation machine learning models such as BART.Design extractor therefore provides a simple quick way toreview longer meeting recordings in the context of softwareengineering decisions.

No description available.

No description available.

No description available.

Much computer communications activity is invisible to the user, happening without explicit permission. When system administrators investigate network communications activities, they have difficulty tracing them back to the processes that cause them. The strictly layered TCP/IP networking model that underlies all widely used, general-purpose operating systems makes it impossible to trace a packet seen on the network back to the processes that are responsible for generating and receiving it. The TCP/IP model separates the concerns of network routing and process ownership so that the layers cannot share the information needed to correlate packets to processes. But knowing what processes are responsible for communications activities can be a great help in determining whether that activity is benign or malicious. My solution combines a visualization tool, a kernel-level correlation engine, and middleware that ties the two together. My research enables security personnel to visually correlate packets to the processes they belong to helping users determine whether communications are benign or malicious. I present my discoveries about the system administrator community and relate how I created a new correlation technology. I conducted a series of initial interviews with system administrators to clarify the problem, researched available solutions in the literature, identified what was missing, and worked with users to build it. The users were my co-designers as I built a series of prototypes of increasing fidelity and conducted usability evaluations on them. I hope that my work will demonstrate how well the participatory design approach works. My work has implications for the kernel structure of all operating system kernels with a TCP/IP protocol stack and network model. In light of my research, I hope security personnel will more clearly see sets of communicating processes on a network as basic computational units rather than the individual host computers. If kernel designers incorporate my findings into their work, it will enable much better security monitoring than is possible today making the Internet safer for all. / Ph. D.