using architecture frameworks. outline software architecture frameworks – these are sets of...
Post on 21-Dec-2015
229 views
TRANSCRIPT
![Page 1: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/1.jpg)
Using Architecture Frameworks
![Page 2: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/2.jpg)
Outline
Software architecture frameworks – These are sets of viewpoint specifications and their relationships.
The 4+1 View Model of architecture – This model was developed by Rational Corporation for describing systems using object-oriented notations.
Reference Model for Open Distributed Processing
This is the ISO/IEC standard for describing open distributed processing systems.
![Page 3: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/3.jpg)
Software Architecture Frameworks
These are frameworks for creating architecture specifications.
They are used as templates. Frameworks include the following types of
viewpoints: Processing (e.g., functional or behavioial
requirements and use cases) Information (e.g., object models, ERDs and
DFDs) Structure (e.g., component diagrams depicting
clients, servers, applications, and databases and their interconnections.)
![Page 4: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/4.jpg)
Philosophies of Architecture Frameworks The differences between the various
frameworks revolve around: Terminology – affects knowledge transference
and reuse (the IEEE 1471 helps by providing a set of terminology).
Representation completeness – should everything be modeled or just that which are considered part of the architectural description.
Selection of viewpoints – is there a prescribed set of viewpoints or is the set highly customizable.
![Page 5: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/5.jpg)
Architecture Framework Goals
Codify best practices for architectural description.
Ensure that the framework sponsors receive architectural information in the format they want.
Facilitate architecture assessment. Improve the productivity of software
development teams by using standardized means for design representation.
Improve interoperability of information systems.
![Page 6: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/6.jpg)
Methodologies and Architecture Frameworks A methodology may incorporate an
architecture framework, but a framework is not a methodology.
A methodology is a collection of: Practices Processes Methods Techniques Diagram notations
![Page 7: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/7.jpg)
The 4 + 1 View Model of Architecture
It is a design methodology developed by Rational Software Corporation and later subsumed by the Rational Unified Process (RUP)
Its goal is to provide a multiviewpoint framework for specifying object-oriented systems.
An architectural description consists of four logical views: logical, process, physical, and development.
A fifth redundant view provides scenarios that tie the other four views together.
![Page 8: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/8.jpg)
The 4 + 1 View Model of Architecture (Cont’d)
End Users
Logical View
Process View
System Integrators
Software Management
Development View
Physical View
System Engineers
Scenarios
addresses
traces to
addresses
addresses
traces to
traces totraces to
addresses
![Page 9: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/9.jpg)
Relationship to IEEE 1471
The definition of a view in the 4 + 1 View Model is loosely defined, sometimes corresponding to an IEEE 1471 view and sometimes to a viewpoint.
Each view addresses a specific set of stakeholder concerns and specifies a metalanguage for the models in that view.
![Page 10: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/10.jpg)
Relationship to IEEE 1471 (Cont’d)
The 4 + 1 Model fails to address the following three concerns specified by IEEE 1471. The appropriateness of the application for use
in fulfilling its purpose. The feasibility of developing the application. The risks of application development and
operation to the stakeholders. For some systems it may be possible to
address these concerns with textual descriptions and a project plan.
![Page 11: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/11.jpg)
Logical Viewpoint
This is a viewpoint for expressing functional requirements.
Logical viewpoints are platform independent. Logical views represent problem domain
concepts, sometimes called the object model or business objects.
This view does not address threads of control.
Objects are considered discrete entities that interact by passing messages.
![Page 12: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/12.jpg)
Stakeholders and Concerns Addressed
The logical view targets the acquirers, end users, developers, and maintainers of the system.
It shows how the functions are decomposed in terms of classes. This helps assure acquirers and end users that the design addresses the intended purpose of the system.
Developers use these models to write code. Maintainers use these models to understand
the system in order to make changes
![Page 13: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/13.jpg)
View Construction
The models for a logical view may be class diagrams or entity relationship diagrams.
An object-oriented architectural style is recommended for this view because of its extensiveness in representing functional capabilities and information requirements.
![Page 14: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/14.jpg)
Process Viewpoint
The process viewpoint is a viewpoint for representing the processing model of the system.
Process views capture the concurrency, synchronization and distribution aspects of the design.
![Page 15: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/15.jpg)
Stakeholders and Concerns Addressed
The process viewpoint addresses acquirers, developers, maintainers, and system integrators.
This view represents the design solution to some nonfunctional requirements such as performance, availability, and fault tolerance.
Acquirers need assurance that the design will satisfy these nonfunctional requirements.
Developers use these models along with the logical model to write the application logic.
Maintainers use these models to understand the system.
System integrators use these models to understand how this system can interoperate with other systems.
![Page 16: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/16.jpg)
View Construction
The process view is described at several levels of abstraction: As communicating processes As tasks that form an executable unit. As components that can be tactically
controlled The process view addresses how logical
objects interact.
![Page 17: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/17.jpg)
View Construction (Cont’d)
The attributes of the classes represented in the process view are: Autonomy – the characteristic that identifies
objects as active, passive, or protected. An active object can invoke its own methods and
the methods of other objects, and has full control over objects invoking its methods.
A passive object never spontaneously invokes other object’s methods and has no control over an object invoking its methods.
A protected object never spontaneously invokes other objects methods but does monitor the invocation of its own methods.
![Page 18: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/18.jpg)
View Construction (Cont’d)
Persistence – the characteristic that identifies objects as either transient or permanent.
Subordination – the characteristic that identifies whether an object’s existence or persistence is dependent on another object.
Distribution – the characteristic that identifies if an object in the logical view is accessible on more than one node in the physical view or accessible from multiple processes from the process view.
![Page 19: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/19.jpg)
View Construction (Cont’d)
The process view can be comprised of class diagrams and collaboration diagrams that focus on the active objects that represent the threads and processes of the system.
The collaboration diagrams can be supplemented with activity and state diagrams.
![Page 20: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/20.jpg)
Development Viewpoint
The development viewpoint is a viewpoint for representing the static organization of the software with respect to the software development environment.
![Page 21: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/21.jpg)
Stakeholders and Concerns Addressed
The development viewpoint addresses software configuration management and concerns such as buildability, maintainability, and reusability.
It also addresses the partitioning of functionality across subsystems in support of development.
![Page 22: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/22.jpg)
View Construction
The components of a development view are modules or subsystems that compose the system.
A layers architectural style can be used in a development view.
The purpose of using layers in the development view is to minimize dependencies on modules so that they can be implemented and compiled with minimal coupling and dependencies.
![Page 23: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/23.jpg)
Physical Viewpoint
The physical viewpoint specifies a means for capturing the mapping of the software onto hardware and specifying its distribution.
![Page 24: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/24.jpg)
Stakeholders and Concerns Addressed
The physical viewpoint addresses acquirers and systems engineers.
This viewpoint addresses the concerns of availability, reliability, performance, and scalability.
![Page 25: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/25.jpg)
View Construction
There can be several physical configurations of the system to support different operational situations.
All the components of the three prior views map onto this view.
The processes are mapped onto hardware nodes.
![Page 26: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/26.jpg)
Scenario Viewpoint
The scenario view ties all the other views together.
Scenarios are instances of use cases. This view is considered to be redundant with
respect to the other four views – it is the “+1” in the framework.
![Page 27: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/27.jpg)
Stakeholders and Concerns Addressed
The scenario viewpoint addresses users, acquirers, developers, maintainers, and testers.
The use cases represent key functional requirements.
The use cases act as a script that ties the elements of the different views together.
![Page 28: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/28.jpg)
View Construction
Only an architecturally significant subset of scenarios is use.
They are represented using object-scenario (UML sequence) diagrams and object-interaction (UML collaboration) diagrams.
![Page 29: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/29.jpg)
Model Overloading
The same types of models are used in different views.
For example, object collaboration diagrams in the logical model may represent key application objects passing general messages and in the process view may show explicit types of method invocations (synchronous, asynchronous, balking).
Also, the same model can have different interpretations depending on the view in which it is interpreted.
![Page 30: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/30.jpg)
Model Overloading (Cont’d)
Because many viewpoints of the 4+1 View Model address both developer and acquirer concerns simultaneously, there are some drawbacks: It forces the acquirer to understand low-level
models. It can all designers to prematurely commit to
implementations.
![Page 31: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/31.jpg)
Architecting with the Unified Process
When the 4+1 View Model was first introduced, UML had not yet been created.
The 4+1View Model has changed and the viewpoints have been renamed as follows: Design view (originally the logical view) Process view Implementation view (was the development view) Deployment view (was the physical view) Use case view (was the scenario)
![Page 32: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/32.jpg)
Architecting with the Unified Process (Cont’d) The static aspect of the design view can be expressed
using class diagrams and object diagrams and the dynamic aspect can use interaction diagrams, statechart diagrams, and activity diagrams.
The process view is the same as the logical view. The implementation view is represented using
component diagrams, interaction diagrams, statechart diagrams, and activity diagrams.
The deployment view is composed of interaction diagrams, statechart diagrams, and activity diagrams.
![Page 33: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/33.jpg)
Reference Model for Open Distributed Processing The main goal of RM-ODP is to provide
mechanisms for architecting distributed processing.
RM-ODP has five viewpoints: Enterprise Information Computational Engineering Technology
![Page 34: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/34.jpg)
Enterprise Viewpoint
This viewpoint focuses on the purpose, scope, and policies of the system and captures system requirements.
![Page 35: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/35.jpg)
Stakeholders and Concerns Addressed
The enterprise viewpoint addresses all stakeholders, but primarily users and acquirers.
It addresses the purpose, missions, and appropriateness of the system.
![Page 36: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/36.jpg)
View Construction
The enterprise viewpoint represents a system in the context of the enterprise in which it operates.
It consists of the following types of elements: Enterprise objects – external systems, people,
artifacts, business processes, the system itself Communities – formed to meet specific objects of the
enterprise Roles – users, owners, providers of information Contracts – a objective in terms of enterprise object
collaborations and constraints
![Page 37: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/37.jpg)
View Construction (Cont’d)
A community specification consists of the following: The specification of enterprise objects that comprise the
community The specification of the roles assumed by those objects The policies governing interactions between enterprise
objects in the assumed roles The policies governing the life-cycle management of
resources used by enterprise objects in the assumed roles The policies governing the structuring of enterprise objects
and their role assignments The policies relating to the environment contracts
governing the system The enterprise view many be composed of use case
models.
![Page 38: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/38.jpg)
Information Viewpoint
The information viewpoint defines the universe of discourse of the system: The information content and the information
about the processing of the system A logical representation of the data in the
system The rules to be followed in the system, e.g.,
policies specified by the stakeholders.
![Page 39: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/39.jpg)
Stakeholders and Concerns Addressed
The information viewpoint addresses the acquirers, endusers, developers, and maintainers of the system.
Architects use this view to organize and communicate system semantics with stakeholders.
The information view can address qualities such as evolvability and adaptability.
![Page 40: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/40.jpg)
View Construction
The information view contains the information object model and environmental contracts for the objects.
The information viewpoint specifies three schemata for representing the information objects: Invariant – specifies what must always be true for a set
of information objects within a given period of time Static – the state and structure of a set of information
objects at a specific point in time Dynamic – all the actions that permit a change in state
or structure of a set of information objects
![Page 41: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/41.jpg)
Computational Viewpoint
This viewpoint specifies the system in terms of computational objects and their interfaces.
It partitions the system into logical objects that perform the capabilities of the system and are capable of being distributed throughout the enterprise.
![Page 42: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/42.jpg)
Stakeholders and Concerns Addressed
This viewpoint addresses the same stakeholders as the information viewpoint.
It addresses the structure of the application as distributed objects without specifying how they are distributed.
![Page 43: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/43.jpg)
View Construction
The elements of the computational viewpoint language are computational objects, computational interfaces, binding objects, interaction types, and interface types.
The three types of interactions are Signal – a one-way interaction between an initiating
object (client) and a responding object (server) Operation – an interrogation (a request and a
response) or announcement (a one-way request) Flow – an ordered set of one or more one-way
communications from a producer object to a consumer object.
![Page 44: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/44.jpg)
Engineering Viewpoint
This view specifies the mechanisms for physical distribution to support the logical processing model of the computational view without specifying a particular technology or middleware platform.
![Page 45: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/45.jpg)
Stakeholders and Concerns Addressed
The engineering viewpoint primarily aggressed the developers and maintainers of the system.
It address the concerns of portability and extensibility.
![Page 46: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/46.jpg)
View Construction
The engineering viewpoint language consists of: Engineering objects – basic engineering objects
correspond to computational objects that specifically provide application services and engineering objects support the distribution mechanisms, infrastructure, binging and transparency.
Nodes – a node is a computer Clusters – configurations of basic engineering objects
that act as a single entity Capsules – units of processing and storage
![Page 47: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/47.jpg)
Technology Viewpoint
The technology viewpoint specifies a language for representing the implementation of a system.
![Page 48: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/48.jpg)
Stakeholders and Concerns Addressed
The technology view primarily addresses developers, maintainers, and testers.
It addresses qualities such as evolvability, maintainability, testability, buildability, extensibility.
![Page 49: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/49.jpg)
View Construction
The technology view maps the other views to implementations, technologies, and standards.
This view specifies how the engineering view, in particular, maps to software, hardware, networks, operating systems, and middleware products.
![Page 50: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/50.jpg)
View Construction
The technology view maps the other views to implementations, technologies, and standards.
This view specifies how the engineering view, in particular, maps to software, hardware, networks, operating systems, and middleware products.
![Page 51: Using Architecture Frameworks. Outline Software architecture frameworks – These are sets of viewpoint specifications and their relationships. The 4+1](https://reader030.vdocuments.net/reader030/viewer/2022032521/56649d565503460f94a35204/html5/thumbnails/51.jpg)
Summary
Frameworks differ with respect to methodology. The 4+1 View Model is tied to a use case driven
methodology. RM-ODP does not have a strong methodology,
but it is much stricter in its modeling languages. The 4+1 View Model focuses on describing
object-oriented systems. The RM-ODP is not tied to object-oriented
systems and is useful for describing open distributed systems.