Spelling suggestions: "subject:"8oftware architecture."" "subject:"5oftware architecture.""
21 |
A transputer based scalable data acquisition systemWard, Michael Patrick January 1995 (has links)
No description available.
|
22 |
A software architecture process for SOA-based enterprise applicationsDias Junior, José Jorge Lima 31 January 2008 (has links)
Made available in DSpace on 2014-06-12T15:51:46Z (GMT). No. of bitstreams: 1
license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5)
Previous issue date: 2008 / O crescimento do tamanho, complexidade e demanda por qualidade dos
sistemas de software são alguns dos motivos que tem aumentado o interesse na
área de arquitetura de software. Consequentemente, processos de arquitetura de
software surgiram a fim de auxiliar os arquitetos na construção dessas
arquiteturas. Arquitetura Orientada a Serviços (SOA) surgiu como um tipo de
arquitetura de software para construir sistemas através da composição de
serviços. Assim como o paradigma de orientação a objetos, o paradigma de
orientação a serviços tem trazido uma abordagem de projeto distinta que
introduz princípios que governam o posicionamento e o projeto dos
componentes arquiteturais. Além disso, SOA é um paradigma para organização
e utilização de capacidades distribuídas que podem estar sob o controle de
diferentes domínios. No contexto empresarial, SOA permite que organizações,
que tenham uma infra-estrutura de aplicações fragmentadas sob a
administração de diferentes áreas de negócio, possam integrar estas aplicações
no nível de serviço. Por um lado, os processos de arquitetura tradicionais não
abrangem estes aspectos de SOA. Por outro lado, as abordagens de SOA
disponíveis não satisfazem todos os fundamentos da arquitetura de software.
Neste sentido, esta dissertação propõe um processo sistemático de arquitetura
de software baseado em SOA que compreende os principais fundamentos da
arquitetura de software e características inerentes a SOA a fim de guiar os
arquitetos na construção de uma descrição arquitetural para SOA.
Adicionalmente, um estudo experimental foi definido, planejado, executado e
analisado a fim de avaliar o processo proposto
|
23 |
Towards controlling software architecture erosion through runtime conformance monitoringde Silva, Lakshitha R. January 2014 (has links)
The software architecture of a system is often used to guide and constrain its implementation. While the code structure of an initial implementation is likely to conform to its intended architecture, its dynamic properties cannot always be fully checked until deployment. Routine maintenance and changing requirements can also lead to a deployed system deviating from this architecture over time. Dynamic architecture conformance checking plays an important part in ensuring that software architectures and corresponding implementations stay consistent with one another throughout the software lifecycle. However, runtime conformance checking strategies often force changes to the software, demand tight coupling between the monitoring framework and application, impact performance, require manual intervention, and lack flexibility and extensibility, affecting their viability in practice. This thesis presents a dynamic conformance checking framework called PANDArch framework, which aims to address these issues. PANDArch is designed to be automated, pluggable, non-intrusive, performance-centric, extensible and tolerant of incomplete specifications. The thesis describes the concept and design principles behind PANDArch, and its current implementation, which uses an architecture description language to specify architectures and Java as the target language. The framework is evaluated using three open source software products of different types. The results suggest that dynamic architectural conformance checking with the proposed features may be a viable option in practice.
|
24 |
Implementing software architecture practices in a new environmentTaylor, Paul Leonardo 2009 August 1900 (has links)
During a discussion with the head of the software infrastructure team about the need for software architecture practices at Temple-Inland Company, the manager responded by noting since the company is not a software development company “there are no real benefits to implementing software development practices in the company”. This is an approach taken by many companies whose software development activity is primarily undertaken to support business activities such as the case with manufacturing or financial companies.
This paper examines the process of implementing software architectural practices into an organization. The information contained here should be useful to small startup software companies who might assume that it is too costly to incorporate software architectural practices into their current development process. This paper should also benefit large organizations who primarily view software as solutions for short term immediate support and not in terms longer term strategic goals. Software development teams with projects that suffer from cost overruns, scheduling problems and user dissatisfaction should also find this information useful. / text
|
25 |
Implementation of a Modular Software Architecture on a Real-Time Operating System for Generic Control over MRI Compatible Surgical RobotsGandomi-Bernal, Katie 25 April 2018 (has links)
Software used in medical settings operate in complex and variable environments. Programs need to integrate well not only with their electrical and mechanical components, but also within the socio-technological setting they participate in. In this Master's Thesis, a modular software architecture for controlling surgical robot systems within magnetic resonance scanners is designed and implemented. The C++ program runs on a sbRIO 9651 real-time operating system and an object oriented design is taken. Robot kinematics and controls are put into effect in software and validated. Communication with up to ten daughter cards occurs via SPI and external information is exchanged via OpenIGTLink. A web-based engineering console made with ReactJS is also constructed to provide a visual interface for actuating motor axes and executing robot functionality. Documentation of the code is provided and the program was validated quantitatively with software tests and qualitatively through experimentation in MRI suites.
|
26 |
Architecture Centric Commenting on ERP System Development - Using SUNON Company as An ExampleYu, Bing-wen 12 January 2004 (has links)
none
|
27 |
Safe and efficient resource sharing in component-based systems /Fiuczynski, Marc Eric, January 2004 (has links)
Thesis (Ph. D.)--University of Washington, 2004. / Vita. Includes bibliographical references (leaves 95-101).
|
28 |
Accident versus essence investigating the relationship among information systems development and requirements capabilities and perceptions of enterprise architecture /Salmans, Brian R. Kappelman, Leon Allan, January 2009 (has links)
Thesis (Ph. D.)--University of North Texas, Aug., 2009. / Title from title page display. Includes bibliographical references.
|
29 |
Development of a software architecture method for software product families and its application to the AubieSat satellite programO'Farrell, John Ryan. Chapman, Richard O. Hamilton, John A. January 2009 (has links)
Thesis--Auburn University, 2009. / Abstract. Includes bibliographic references (p.82-85).
|
30 |
An Exploration of the Architecture of First Person Shooter GamesPrashar, CHARU 14 January 2014 (has links)
First Person Shooter (FPS) games are one of the most popular game genres and have a history of over 2 decades. While there has been extensive research on such games, the focus has been limited to their analysis at an individual level. In this thesis, we present a comparative analysis of three first person shooter games - Doom, Quake3 and Cube from an architectural point of view. All of these games have come at different times in the history of first person shooter games, and thus possess different and unique features. We describe the process followed in deriving their architecture at various levels of abstraction – the file level, the subsystem level, the library/non-library level and the individual subsystem level for a given part of code. We conclude with a comparative analysis of the similarities and differences in the structure and architecture of the three gaming systems. / Thesis (Master, Computing) -- Queen's University, 2014-01-13 15:26:25.387
|
Page generated in 0.411 seconds