Mdsd capable target architecture
- 2. Software Architecture in Context of MDSD MDSD perspective on the topic of software architecture leads us to the term target architecture that contains the platform architecture. MDSD domain architecture is also software architecture. It defines the whole of the metamodel, DSL, and platform, as well as transformations. Software architecture is describes the most important platform components, their interactions, as well as their non-functional characteristics, which is it platform architecture. Software architecture also plays a role in MDSD transformations, because it actually defines the software architecture of the generated code, it is call Transformation architecture. Software architecture is tool architecture.
- 3. What is Sound Architecture? • The Architecture must support the functional requirements, non functional requirements, simpler, easier to understand and practicable, well document that includes a brief and concise documentation of all the points is called Sound Architecture.
- 4. How do you arrive any Sound Architecture? • Through Architectural Patterns and Styles, like this example: • A proven way of obtaining a good architecture is the use of a tried and tested architectural pattern or style as basis of one’s own architecture.
- 5. Building Blocks for Software Architecture • Framework are anything that can be adapted or extended via systematic extension or configuration. Frameworks are DSLs. MDSD platforms can be very well implemented with the help of frameworks. Typical examples of frameworks are J2EE and .NET. • Middleware can be seen as a kind of framework. It is specific to a technical domain such as distributed systems, messaging, or transactions. Well-known examples are CORBA, DCOM, MQSeries, and CICS. • Components is a self-contained piece of software with clearly-defined interfaces and explicitly declared context dependencies.
- 8. Balancing the MDSD Platform • MDSD domain and the MDSD platform should be as close to each other as possible. • The MDSD platform should ‘meet the MDSD domain halfway known rich domain specific platform. • Reference model is concerned for reducing the conceptual distance between domain and platform: – MDSD domain and platform are located at the level of the reference model’s technical platform. – MDSD domain and platform are at the level of the target architecture’s concepts. – MDSD domain and platform are at the level of the functional/professional platform of the reference architecture.
- 9. Architecture Conformance • Good target architecture can exhibit its advantages only if it is not ignored or circumvented in the daily project routine. • Traditional methods such as reviews and excessive documentation are not easily scalable when working with bigger teams. • For generated code, MDSD offers the solution, particularly because the aspects of the architecture that are described using the models are laid down in the form of transformation rules.
- 10. MDSD and CBD • 1st Viewpoint • Type Viewpoint describes component types, interfaces, and data structures. A component provides a number of interfaces and references a number of required interfaces. An interface owns a number of operations, each with a return type, parameters, and exceptions.
- 12. MDSD and CBD • 2nd Viewpoint • Composition Viewpoint describes component instances and how they are connected. A configuration consists of a number of component instances, each knowing their type. An instance has a number of wires: a wire is an instance of a component interface requirement.
- 14. MDSD and CBD • 3rd Viewpoint • System Viewpoint describes the system infrastructure onto which the logical system defined with the two previous viewpoints is deployed.
- 17. Aspects of Models Persistence Authorization and Authentication (important in enterprise systems) Forms, layout, Pageflow (for Web applications) Timing, scheduling and other quality of service aspects (especially in embedded systems) Packaging and deployment Diagnostics and monitoring
- 19. Component Implementation • Component implementation typically happens manually. • Developers add manually written code to the component skeleton, either by adding the code directly to the generated class, or by using other means of composition such as inheritance or partial classes. • The main reason is that action languages that support the generic formulation of application logic at the model level are still not widely supported.
- 20. SOA (Service-Oriented Architecture) • SOA has nothing to do with specific technologies (WSDL, SOAP, HTTP), a set of architectural best practices for building large, scalable, and compose able systems. • A well-constructed component-based architecture with well-defined interfaces and clear-cut component responsibilities can quite justifiable is considered SOA.
- 21. BPM (Business Process Management) • BPM deals with design and control of business processes • BPM respects the complete lifecycle of a business process (definition, creation, execution, monitoring, optimization) • BPM is not a product and none of the following single product categories can be said to cover BPM completely: workflow, enterprise application integration (EAI), business activity monitoring (BAM), rules engines, and process-simulations. • Ideally they can be part of a system that supports BPM.
- 22. SOA and BPM relationship • An intersection of SOA and BPM exists: modeling and specification of business processes on one hand, and respective infrastructure software (middleware) on the other. • SOA covers business process modeling through BPEL (Business Process Execution Language) which is based on and coupled to Web Service technology. • BPM covers business process modeling through more abstract language concepts and (graphical) notations. • So from a specific point of view we can say that SOA is a bottom-up evolution and BPM a top-down one.