1. Using Architecture Frameworks

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

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

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

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

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

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

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

9. Relationship to IEEE 1471
The definition of a view in the 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.

10. Relationship to IEEE 1471 (Cont’d)
The 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

24. Stakeholders and Concerns Addressed
The physical viewpoint addresses acquirers and systems engineers.
This viewpoint addresses the concerns of availability, reliability, performance, and scalability.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

45. Stakeholders and Concerns Addressed
The engineering viewpoint primarily aggressed the developers and maintainers of the system.
It address the concerns of portability and extensibility.

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

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

48. Stakeholders and Concerns Addressed
The technology view primarily addresses developers, maintainers, and testers.
It addresses qualities such as evolvability, maintainability, testability, buildability, extensibility.

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

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

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