Using Architecture Frameworks

1
Using Architecture Frameworks
2
Outline

• Software architecture frameworks
• These are sets of viewpoint specifications and
  their relationships.
• The 41 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 (Contd)
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 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.

10
Relationship to IEEE 1471 (Contd)

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

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 (Contd)

• 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 objects 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 (Contd)

• Persistence the characteristic that identifies
  objects as either transient or permanent.
• Subordination the characteristic that
  identifies whether an objects 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 (Contd)

• 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 (Contd)

• Because many viewpoints of the 41 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 41 View Model was first introduced, UML
  had not yet been created.
• The 41View 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 (Contd)

• 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 (Contd)

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