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 Software Management addresses addresses traces to Logical View Development View Scenarios traces to traces to traces to Process View Physical View addresses addresses System Integrators System Engineers

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.