Using Architecture Frameworks

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.

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.)

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.

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.

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

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.

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

Development Viewpoint

The development viewpoint is a viewpoint for representing the static organization of the software with respect to the software development environment.

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.

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.

Physical Viewpoint

The physical viewpoint specifies a means for capturing the mapping of the software onto hardware and specifying its distribution.

Stakeholders and Concerns Addressed

The physical viewpoint addresses acquirers and systems engineers.

This viewpoint addresses the concerns of availability, reliability, performance, and scalability.

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.

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.

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.

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.

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.

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.

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)

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.

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

Enterprise Viewpoint

This viewpoint focuses on the purpose, scope, and policies of the system and captures system requirements.

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.

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

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.

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.

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.

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

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.

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.

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.

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.

Stakeholders and Concerns Addressed

The engineering viewpoint primarily aggressed the developers and maintainers of the system.

It address the concerns of portability and extensibility.

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

Technology Viewpoint

The technology viewpoint specifies a language for representing the implementation of a system.

Stakeholders and Concerns Addressed

The technology view primarily addresses developers, maintainers, and testers.

It addresses qualities such as evolvability, maintainability, testability, buildability, extensibility.

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.

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.

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.