Difference between revisions of "Architecture/Visions"
m |
m |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
Owner: [[SZ|Stefan Zimmermann]] mentored by [[KR|Kay Ramme]] Type: visions State: draft | Owner: [[SZ|Stefan Zimmermann]] mentored by [[KR|Kay Ramme]] Type: visions State: draft | ||
| − | + | '''''"Ideal software architecture of large software systems like OpenOffice.org with consequent implemented Model-View-Controller scheme, multithreading and event-based programming." | |
| + | ''''' | ||
| + | |||
==MVC== | ==MVC== | ||
| Line 7: | Line 9: | ||
{{:Architecture/Visions/Service_Oriented_Architecture}} | {{:Architecture/Visions/Service_Oriented_Architecture}} | ||
{{:Architecture/Visions/Service_Component_Architecture}} | {{:Architecture/Visions/Service_Component_Architecture}} | ||
| + | ==Software architecture and event driven programming== | ||
| + | |||
[[Category:Vision]] | [[Category:Vision]] | ||
Latest revision as of 20:03, 15 May 2008
Owner: Stefan Zimmermann mentored by Kay Ramme Type: visions State: draft
"Ideal software architecture of large software systems like OpenOffice.org with consequent implemented Model-View-Controller scheme, multithreading and event-based programming."
Contents
MVC
Consequent implementation of the Model-View-Controller ( MVC ) paradigm
When software applications contain a mixture of data access code, business logic code, presentation code and control logic they appear to be increasingly difficult to maintain. With the increased size of an application the complexity gets fast out of control because of interdependencies between all of the components. Changes become increasingly difficult, reuse of classes are nearly impossible because of their heavy dependency on too many other classes. Changes or additions to the functionality of the application in terms of new views on data too often require re-implementation or doubling of existing business logic as well as data access code for adaption. This in turn leads to an again increased maintenance effort because changes have to be made at different code locations and needs to be hold in sync.
In large software systems the spiral of tightly coupled code, poor re-usage of classes/functionality and copy-pasted code, often leads to extreme maintenance efforts and significant longer time to market cycles.
A Model-View-Controller ( MVC ) architectural design pattern offers here a way of decoupling data access, business logic, data presentation and user interaction by defining three categories of objects, each specialized on either data access and business logic (Model), the presentation of data (View) or the handling of interaction events (Controller).
The separation of this three categories, known as MVC triad (which origins from Smalltalk80), allows for e.g. different views on the same, shared data model. Consequently implemented in a software system with strictly separated, specialized object categories the MVC like architectural pattern leads to increased re-usage opportunities for classes, better modularity, better scalability, less dependencies between classes and therefor better maintainability of the entire system.
This can only apply when the MVC triad like pattern is transparent to the contributing developers and implemented according to an overarching strategy throughout the entire software system. The challenge in the scope of large software systems like OpenOffice.org is to analyze if and how the MVC paradigm is followed and how contributing developers can be lead to a unified understanding, handling and implementation of this architectural design pattern.
It should be emphasized that MVC here is called a paradigm and should be seen more as an architectural strategy which aims for clear functional separation of classes. What flavor of the MVC paradigm to prefer, is left to imagination and creativity. Is it Presentation-Abstraction-Control (PAC) pattern, Interface-Model_Control (ICM), or a subset or variation of PAC like Hierarchical Model-View-Controller pattern (HMVC).
All of these seem to offer compelling advantages wrt. user experience especially startup time experience due to the possibility of separately multithread the model and the view.
Service-Oriented Architecture (SOA)
Service-orientation describes an architecture that uses loosely coupled independent services to provide resources that can be accessed without knowledge of their underlying platform implementation. The key is independent services with defined interfaces that can be called to perform their tasks in a standard way, without the service having foreknowledge of the calling application, and without the application having or needing knowledge of how the service actually performs its tasks. SOA is a style of information systems architecture that enables the creation of applications built by combining loosely coupled and interoperable services based on a formal interface definition that is independent of the underlying platform and programming language. The interface definition hides the implementation of the language-specific service. SOA-based systems can therefore be independent of development technologies and platforms.
Service Component Architecture (SCA)
Applications designed with Service Component Architecture (SCA) should have the following properties:
- Decoupling of service implementation and of service assembly from the details of infrastructure capabilities.
- Ablility to work with multitude of programming languages
- Ability to work with various messaging constructs including One-Way, Asynchronous, Call-Return, and Notification.
- Infrastructure capabilities, such as Security, Transactions and the use of Reliable Messaging should be applied to code through metadata.
- Data should be represented in Service Data Objects.
- Components designed in SCA should be easily reused.
- Local calls to services should be more tightly coupled, reducing the overhead of creating and parsing messages intended for transport over a network.
