When designing work tasks, one goal should be to enable postures that maximize the force capabilities of the workers while minimizing the overall muscular demands; however, little is known regarding specific shoulder tissue loads during pushing and pulling. This study quantitatively evaluated the effects of direction (anterior-posterior pushing and pulling), handle height (100 cm and 150 cm), handle orientation (vertical and horizontal), included elbow angle (extended and flexed) as well as personal factors (gender, mass and stature) on hand force magnitudes, shoulder and L5/S1 joint moments, normalized mean muscle activation and electromyography (EMG)/force ratios during two-handed maximal push and pull exertions. Twelve female and twelve male volunteers performed maximal voluntary isometric contractions under 10 push and pull experimental conditions that emulated industrial tasks. Hand force magnitudes, kinematic data and bilateral EMG of seven superficial shoulder and trunk muscles were collected. Results showed that direction had the greatest influence on dependent measures. Push exertions produced the greatest forces while also reducing L5/S1 extensor moments, shoulder moments with the 150 cm height and overall muscular demands (p < 0.0001). The 100 cm handle height generated the greatest forces (p < 0.0001) and reduced muscular demands (p < 0.05), but were associated with greater sagittal plane moments (p < 0.05). Females generated, on average, 67% of male forces in addition to incurring greater muscular demands (p < 0.05). The flexed elbows condition in conjunction with pushing produced greater forces with reduced overall muscular demands (p < 0.0001). Furthermore, horizontal handle orientation caused greater resultant moments at all joints (p <. 0.05) The results have important ergonomics implications for evaluating, designing or modifying workstations, tasks or equipment towards improved task performance and the prevention of musculoskeletal injuries and associated health care costs.

Feature-oriented requirements decompose a system's requirements into individual bundles of functionality called features, where each feature's behaviour can be expressed as a state-machine model. However, state machines are difficult to write; determining how to decompose behaviour into states is not obvious, different stakeholders will have different opinions on how to structure the state machine, and the state machines can easily become too complex. This thesis proposes a pattern for decomposing and structuring the model of a feature's behavioural requirements, based on modes of operation (e.g., Active, Inactive, Failed) that are common to features in multiple domains. Interestingly, the highest-level modes of the pattern can serve as a generic behavioural interface for all features that adhere to the pattern. The thesis proposes also several pattern extensions that provide guidance on how to structure the Active and Inactive behaviour of the feature. The pattern was applied to model the behavioural requirements of 21 automotive features that were specified in 7 production-grade requirements documents. The pattern was applicable to all 21 features, and the proposed generic feature interface was applicable to 50 out of 58 inter-feature references. A user study with 18 participants evaluated whether use of the pattern made it easier than otherwise to write state machines for features and whether feature state machines written with the help of the pattern are more readable than those written without the help of the pattern. The results of the study indicate that use of the pattern facilitates writing of feature state machines.

Purpose: To describe patient & tumor characteristics among rectal cancer patients in Nova Scotia, to determine factors associated with permanent colostomy and oncologic outcomes and to determine the relationship between surgeon knowledge and oncologic outcomes.Methods:The Provincial cancer registry identified new rectal cancer patients from in Nova Scotia. A comprehensive review of inpatient, outpatient and cancer center medical records was used to assemble the cohort. Surgeon knowledge was assessed using a survey with questions pertaining to rectal cancer care.Results: Patient & tumor characteristics were similar between hospitals providing rectal cancer care. Patients treated by high volume cancer center surgeons are less likely to undergo a permanent colostomy or have a local recurrence compared to patients treated elsewhere. Patients treated by surgeons with a high survey score have improved clinical and oncologic outcomes.Conclusions: There is an opportunity to improve rectal cancer care in Nova Scotia.

A business application automates a collection of business processes. A business process describes how a set of logically related tasks are executed, ordered and managed by following business rules to achieve business objectives. An “online book purchase” business process contains several tasks such as buying a book, ordering a book, and sending out promotions. In this ever changing business environment, both of business applications and business processes are modified to accommodate changed business requirements and improve the performance of the organization. These continuous modifications introduce problems in the following two aspects: 1) Business process definitions are rarely updated to reflect the current business processes deployed in business applications. 2) Business processes may be cloned (e.g., copied and slightly modified) to handle special circumstances or promotions. Identifying these clones and removing them help improve the efficiency of an organization. However, business processes are defined with textual languages that cannot be automatically understood. To maintain business process definitions up to date, we present our techniques that automatically recover business processes from UIs of business applications and identify clones in the recovered business processes. We leverage UI design patterns, which present the best practices of UI designs, to capture business processes from UIs. To refine the recovered business processes and mark the functionally equivalent tasks, we use existing code clone detection tools, such as CCFinder and CloneDR, to detect clones in business applications, and lift clones from code level to business process level. The effectiveness of our techniques is demonstrated through a case study on 15 large open source business applications. / Thesis (Master, Computing) -- Queen's University, 2008-10-28 11:06:31.41

This thesis presents a Web services implementation of the infrastructure for e-Marketplaces based on e-Marketplace business patterns. Business patterns implemented by the infrastructure include User-to-Business, User-to-Online Buying, User-to-User, and Business-to-Business integration. The implementation of the User-to-Business pattern provides for all non-commercial user transactions with the e-Marketplace, including the registration processes, aggregating the e-Marketplace catalog with product and service offers, response to requests for quote, and purchase order checking and processing. The implementation of the User-to-Online Buying pattern provides for all commercial transactions that a user may conduct with the e-Marketplace, including catalog-based buying, contract-based buying, auction bidding, exchange bid offering, and the publication of requests for quote. The implementation of the User-to-User pattern supports e-Marketplace user communication. The implementation of the Business-to-Business integration pattern enables commerce systems of the suppliers and procurement systems of the buyers to integrate with the e-Marketplace to conduct commerce and non-commerce transactions. <br><br> The implemented e-Marketplace infrastructure provides a foundation for building concrete e-Marketplaces, by e-Marketplace builders, to present the e-Marketplace functionalities to the end users such as e-Marketplace administrators and traders. The infrastructure is implemented using Web services technology to provide system-independent accessibility to clients of concrete e-Marketplaces that are built on the infrastructure. The infrastructure implements the business patterns in the form of groups of collaborating Web services.

No description available.

No description available.

No description available.

In this work object-oriented patterns were used for development of gata processing system on the Web. Nowadays a lot of systems are developing for they use in internet. In my final work these patterns were used: MVC, Page Controller, Front Controller, Intercepting Filter and others. Model-View-Controller pattern separates the modeling of domain, the presentation, and the actions based on user input into three separate classes: Model, View, Controller. This pattern is a fundamental design pattern for separation of user interface logic from business logic. Unfortunately, the popularity of the pattern has resulted in a number of faulty descriptions. Using a Page controller for a Web application is such a common need that most Web application frameworks provide a default implementation of the page controller. Most frameworks incorporate the page controller in the front of server page. Server pages actually combine the functions of view and controller and do not provide the desired separation between the presentation code and controller code.A common implementation of Page Controller invokes creating a base class for behavior shared among individual pages. Front Controller solves the decentralization problem present i Page Controller by chanelling all requests through a single controller. The controller itself is usually implemented in two parts: a handler and a hierarchy of commands. A straightforward implementation of Interceptong Filter is a filter chain that iterates through a... [to full text]

This work analyzes the possible ways for implementing electronical services in cardiology. There are many technologies that can be used to implement electronical services. In this case the WEB page generation and WEB services technology was chosen. There was no appropriate design pattern that matches the requirements. Front Controller is one of the possible problem solutions, but it does not describe any way of distributing the system. Front Controller design pattern is not an appropriate solution when there are huge calculations to be done and expected user count will be growing constantly. Broker design pattern solves this problem, but it has its disadvantage, that every server needs to have a real IP address. One of the constraints in this work is that server does not need to have an external IP address. The proposed broker design pattern implements task distribution through many servers solves the problem that every server does not need external IP address. The system also solves the aviliability problem, so it can handle huge number of users. Theoretical experiments proved that, when the number of users using the system is low, the Front Controller approach is more effective, but when the number of users grows at some point this approach can not handle all the user requests. In this case the proposed Broker design pattern approach solves the problem. The proposed broker design patter was successfully implemented in real life and has been tested to be functional.