B345 Internet Science and Technology 
Week 3 lecture 2

Prelude
- Today's lecture handout



This lecture's Learning Objectives
- Understand the steps involved in creating a Software Architecture Description.
- Learn to use two example Software Architecture Frameworks to construct architecture descriptions.
    - The 4+1 View Model
    - RM-ODP

Steps Involved in Creating an Architecture Description
- From IEEE 1471
    - Identify what to include in the description 
    - Identify stakeholders, and their concerns
    - Select and specify viewpoints
    - Specify views
    - Record inconsistencies between views
    - Create rationale for the architecture

Identify Stakeholder
- At least
    - Owners of the system
    - Users of the system
    - Developers of the system
    - People who maintain and support the system

Identify Concerns
- At least
    - Purpose
    - Appropriateness of system to fulfill purpose
    - Feasibility to develop
    - Risks in developing and operating
    - Maintainability, deployability, and evolvability

- Other other more specific concerns
    - Extensibility, modularity, adaptability, performance.

Specify Viewpoints
- Techniques and models for constructing views.
- At least specify
    - Viewpoint name
    - Stakeholders addressed
    - Concerns addressed
    - How to create view from viewpoint
    - Source for a library viewpoint

Architectural Frameworks
- Templates for architectural descriptions consisting of multiple viewpoint specifications, and relationships between the viewpoints
- None follows IEEE 1471 completely, but the goals are similar.

Why Architectural Frameworks?
- Ease communication between stakeholders.
- Consistency is development process
    - Transfer and reuse knowledge across projects and people.

Framework vs Methodology
- Methodology can include a Framework, but not vice-versa.
- More in Topic 3.

4+1 View Model
- Developed by Rational Software Corporation.
- Related to RUP.

4+1 View Model
- 4 Views:
    - Design
    - Process
    - Implementation
    - Deployment
- One redundant view:
    - Use case

Design View
- Represent functional requirements.
- Stakeholders:
    - Acquirers (owners)
    - End users
    - Developers
    - Maintainers 

Process View
- Represent the processing model of the system.
    - Tasks to be done
- Stakeholders:
    - Acquirers (owners)
    - Developers
    - Maintainers 
    - System integrators

- Addresses some non-functional requirements like performance, availability, fault tolerance.

Implementation View
- Represents the static organization of the software.
- Stakeholders:
    - Acquirers (owners)
    - Developers
    - Maintainers 
    - System integrators

Deployment View
- Maps the software onto the hardware locations.
- Stakeholders:
    - Acquirers (owners)
    - System engineers.

Use Case View
- Ties all the other views together.
    - Use elements from all the other views to construct use cases. 
- Stakeholders
    - Could be everyone.

Reference Model for Open Distributed Processing (RM-ODP)
- For distributed information systems, and for enterprise application integration.
- Views:
    - Enterprise
    - Information
    - Computational
    - Engineering
    - Technology 

Enterprise View
- Purpose, scope, policies of the system. 
- Requirements of the system in relations to the enterprise.
- Stakeholders
    - Acquirers
    - End users

Information Viewpoint
- How to define the information content and information processing within the system.
- Similar to functional requirements in 4+1 Model View.
- Stakeholders:
    - Acquirers
    - End users
    - Developers
    - Maintainers.

Computational View
- Represents the computational objects and how they interact.
- Stakeholders
    - Acquirers
    - End users
    - Developers
    - Maintainers.

Engineering View
- Specifies the mechanisms for supporting the processing as defined by the computational view.
    - Without specifying the technology or platform.
- Stakeholders
    - Developers
    - Maintainers

Technology View
- Represents the implementation of the system (technologies, platforms, languages, etc).
- Stakeholders
    - Developers
    - Maintainers
    - Testers