The document discusses software architecture in the context of model-driven software development (MDSD). It defines key MDSD concepts like target architecture, domain architecture, and transformation architecture. It also covers what constitutes a sound architecture, how to arrive at one through patterns and styles, and important building blocks like frameworks, middleware, and components. The document discusses balancing the MDSD domain and platform, architecture conformance, viewpoints in modeling architectures, and implementing components. It relates MDSD concepts to service-oriented architecture (SOA) and business process management (BPM).

1. MDSD-Capable Target
Architecture
Chap # 7

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.

7. Architecture Reference Model

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.

16. Viewpoint Dependencies

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.