ViewpointModelingcanal/sabc/ViewpointModeling.pdf · ODS, Enterprise Architecture, Viewpoints, Models 3. Modeling approaches and standards •IEEE Std 1471 •Krutchen’s4+1 model

1

Viewpoint ModelingAntonio Vallecillo

Universidad de Málaga

Dpto. Lenguajes y Ciencias de la Computación

[email protected]

http://www.lcc.uma.es/~av Master en Ingeniería del Softwaree Inteligencia Artificial

Universidad MálagaMaster en Ingenería del Software e Inteligencia Artificial 2

Agenda

1. Viewpoint Modeling

2. ODS, Enterprise Architecture, Viewpoints, Models

3. Modeling approaches and standards

• IEEE Std 1471

• Krutchen’s 4+1 model

• Zachman’s Framework

• ISO/IEC, ITU-T Open Distributed Processing Reference Model

2


Large distributed systems

A system is distributed when it executes spread over a set of computers

Properties of distributed systems:Concurrency (efficiency, total execution time)

Scalability and ordered growth

Allow for mobility, replication,

…

Problems of distributed systems:No global view of the system

Complex design, management, maintenance and evolution

Communication delays and errors, possible QoS degradation

No global clock (difficult synchronization among processes)

Compatibility and interoperability problems (heterogeneity)

Event races, asynchrony,…

Distributed systems are more difficult to verify and test


Examples of large distributed systems

Client-server systems

Web applications (3-4 tiers)Yahoo!, Google, Airlines portals, Banks portals, etc.

Most commercial systems for retail shopsInclude several POS in a shop, shop servers, business server, warehouse computers, connection to financial services (banks, credit cards), suppliers, etc.

Process farmsSETI@home, folding@home

P2P systems (Napster), Emule, KaZaA

Avionics and space systemsLarge and heterogeneous systems, many participants, many kinds of devices, embedded computers, critical operations

3


Open systems

A system is open if its specifications are available

This include making available information about:

The standards it conforms to (international or de-facto)

The software architecture of the system

The interfaces required to interoperate with the system, exchange information with it, and extend it

Open systems are independently extensible

Open systems are different from open source systems

None of these implies the other

Open systems are not necessarily distributed systems

But here we will deal with Open and Distributed Systems


Goals of ODS

Portability of services and applications

Interoperability between systems and services from different providers and parties

Reusability

Transparencies

Access (invocation mechanisms and languages)

Failure

Location, Migration, Relocation

Replication

Transactions

Extensibility and evolution

Modularity and decoupling

4


Viewpoint modeling

Different stakeholders see the system from different perspectives

Managers, developers, maintainers, users, owner

There are too many different concerns that need to be addressed in the design of an ODS

Functionality, security, distribution, heterogeneity,…

Viewpoint modeling is commonly used in other (more mature) engineering disciplines

Different maps for a building (floor plants, electricity, water conductions, heating system, etc.)

Different maps for a city (physical, metro, buses, etc.)


Viewpoint modeling initiatives

Based on IEEE Std. 1471

This standards defines the main concepts and sets the global picture

Commonly used in most modeling approaches

UML (structural view, behavioural view)

Web Engineering (Navigation, Presentation, Data, Process, etc.)

MDA (CIM, PIM, PSM)

…

Main proposals for Enterprise Architecture

Kruchten’s “4+1 views”

Zachman’s framework

DoD’s TOGAF

ISO/IEC and ITU-T’s RM-ODP

5


IEEE Std. 1471 (2000)

“IEEE Recommended Practice for Architectural Description of Software-Intensive System”Scope• Expression of the system and its evolution• Communication among the system stakeholders• Evaluation and comparison of architectures in a consistent

manner• Planning, managing, and executing the activities of system

development• Expression of the persistent characteristics and supporting

principles of a system to guide acceptable change• Verification of a system implementation’s compliance with an

architectural description• Recording contributions to the body of knowledge of software-

intensive systems architecture

Purpose“To facilitate the expression and communication of architectures and thereby lay a foundation for quality and cost gains through standardization of elements and practices for architectural description.”


IEEE 1471 Main concepts

Architect: The person, team, or organization responsible for systems architecture.

Architectural description: A collection of products to document an architecture.

Architecture: The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.

System: A collection of components organized to accomplish a specific function or set of functions.

View: A representation of a whole system from the perspective of a related set of concerns.

Viewpoint: A specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audience for aview and the techniques for its creation and analysis.

6


IEEE 1471 conceptual model of architectural description


IEEE 1471 viewpoints

An AD shall identify the viewpoints selected for use, and include a rationale for the selection of each viewpoint

Each viewpoint shall be specified bya) A viewpoint name,

b) The stakeholders to be addressed by the viewpoint,

c) The concerns to be addressed by the viewpoint,

d) The language, modeling techniques, or analytical methods to be used in constructing a view based upon the viewpoint,

e) The source, for a library viewpoint (the source could include author, date, or reference to other documents).

A viewpoint specification may include additional information:Formal or informal consistency and completeness tests to be applied to the models making up an associated view

Evaluation or analysis techniques to be applied to the models

Heuristics, patterns, or other guidelines to assist in synthesis of an associated view

7


Viewpoint completeness and consistency

An architectural description is consistent if none of its views imposes contradictory requirements on the rest of the viewpoints

An architectural description is complete if it contains all the information required by the different kinds of stakeholders


Viewpoint examples

UML views

Requirements, Structure, Behaviour, Deployment

Web Engineering viewpoints

Navegation (hypertext)

Presentation (and adaptation)

Business Logic (processes)

MDA

Computation Independent Viewpoint (CIMs)

Platform Independent Viewpoint (PIMs)

Platform Specific Viewpoint (PSMs)

8


Krutchen’s “4+1 view model”


Krutchen views

The logical view is the object model of the design (when an object-oriented design method is used),

The process view captures the concurrency and synchronization aspects of the design,

The physical view describes the mapping(s) of the software onto the hardware and reflects its distributed aspect,

The development view describes the static organization of the software in its development environment

The scenarios illustrate the system requirements and its basic functionality by means of use cases

Scenarios are used at the beginning to capture the system requirements, to identify the mayor elements of the system, and at the end to illustrate and validate the system design

Correspondences show how elements in one view relate to elements in other views

9


Considerations about the “4+1 view model”

It prescribes the viewpoints that should compose the architectural description of a system

Not all views are required in all cases

E.g., for small systems

It is methodology-independent

Although IBM used it as the basis for RUP (v1)

It is also notation-independent

UML supports well its views (apart from the development view)


Zachman’s framework

10


Considerations about the Zachman Framework

It prescribes the viewpoints that should compose the architectural description of a system

It is very detailed

Probably too much!

It means at least 36 high-level models for an application

Zachman thinks all views are required in all cases

Even for small systems

It is methodology-independent

The Popkin process tries to fill this gap

It is also notation-independent

Sowa tried to formalize some of the views


ODP Framework

The Reference Model of ODP (ITU-T Rec X.901-904 | ISO/IEC 10746) defines a framework for system specification, covering all aspects of ODS:

“enterprise” context, data, functionality, distribution, technology

It comprisesA structure for system specifications in terms of viewpoints

A set of object-oriented foundation modeling conceptscommon to all viewpoint languages

A language (concepts and rules) for expressing each viewpoint specification

A set of correspondences between the viewpoints

A set of common functions

A set of transparencies

A set of conformance points

A framework for ODP standards

11


ODP Viewpoints

Different abstractions of the same system

each abstraction focuses on different concerns

each abstraction achieved using a set of viewpoint concepts and rules

A viewpoint specification

Is a specification of a system from a specific viewpoint

is expressed in terms of the viewpoint concepts and rules (the viewpoint language) to describe the concerns and decisions covered by the viewpoint specification

Is related to, and consistent with, other viewpoint specifications (correspondences)


ODP Viewpoints—different concerns

SystemSystem

EnterpriseEnterprise

ComputationalComputational

InformationInformation

TechnologyTechnology

EngineeringEngineering

12


An ODP system specification

- Object configuration- Interactions between

objects at interfaces

Computational

Enterprise- business aspects- What for? Why? Who? When?

- information- changes to information- constraints

Information

- Hardware and software componentsimplementing the system

Technology

Engineering

- Mechanisms and servicesfor distribution trans-parencies and QoS constraints.

- and correspondences between specifications


ODP Correspondences

Enterprise

Information Computational Engineering Technology

13


The enterprise specification

Specifies the roles played by the system in its organizational environment

An object model of, for example, part of some social/commercial organization in terms of:

Communities (of enterprise objects)

Objectives

Enterprise objects

BehaviourRoles (fulfilled by enterprise objects in a community)

Processes (leading to Objectives)

Policies

Accountability

The system is just another object


Example: A Bank Information System

A bank is composed of branches, spread all over the country

The bank’s central office manages and coordinates the branches’ activities

Each branch has a manager and is responsible to provide banking services to its customers

Branches may interact with each other and with the bank central office

Each branch will have an ATM and a main server, and each branch’s employee will have a computer and a printer

The Bank information system (BIS) will manage all IS-related issues

14


BIS – Enterprise specification

Each branch, and will be specified by a communityIts goal is to “provide banking services to its customers”

Its objects model the branch entities: people (“Joe Smith”, “Lucy Brown”), computers (PC #123-45, printer #xyz), concrete bank accounts, etc.

Its roles are: branch manager, controller, customer (active),…, or bank account, money, etc. (passive)

Assignment policies (e.g., the requirements of a person to become a customer)

Policies:Permissions: what can be done, e.g. money can be deposited into an open account

Prohibition: what must not be done, e.g. customers must not withdraw more than 600 Euros per day

Obligations: what must be done, e.g. the bank manager must advise customers when the interest rate changes, customers must presentsome ID for withdrawing money.

Authorizations: accounts of some VIP customers are allowed to have overdrawn.


BIS – Enterprise specification (ct’d)

Environment contracts: e.g., transactions performed using other banks’ ATMs should have effect within at most 24 hours; information about a branch’s customers cannot be disclosed to other branches

Accountability: e.g., the branch manager is responsible for authorizing an overdrawn, but can delegate to the branch’s controller officer

The bank’s central office will be specified by another community

It’s goal is to “manage and coordinate the branches’ activities”

It’s objects are…

It’s roles are …

It’s assignment policies are…

It’s policies are…

Environment contracts…

Accountability….

Branches may interact with each other and with the bank central office

15


The information specification

Specifies system behavior to fulfill its enterprise roles, abstracted from implementation

An object model of the system describing the semantics of information and of information processing in the system, in terms of:

Information objects

Invariant schema: predicates on information objects that must always be true

Static schema: state of information objects at some location in time

Dynamic schema: allowable state changes of information objects


BIS – Information specification

Describes a model with the information types, their relationships, and constraints on these types and relationships

e.g., a bank account consists a balance and the “amount-withdrawn-today”.

Static schema captures the state and structure of a object at some particular instance

e.g., at midnight, the amount-withdrawn-today is 0.

An invariant schema restricts the state and structure of an object at all times

e.g., the amountwithdrawn-today is less than or equal to 600.

A dynamic schema defines a permitted change in the state and structure of an object

e.g. a withdrawal of $X from an account decreases the balance by $X and increases the amount-withdrawn-today by $X.

Static and dynamic schema are always constrained by invariant schemata

$400 could be withdrawn in the morning but an additional $200 could not be withdrawn in the afternoon as the amount-withdrawn-today cannot exceed $500.

Schemas can also be used to describe relationships or associations between objects

e.g., the static schema “owns account” could associate each account with a customer.

16


The computational specification

Specifies computational structure of the system in terms of units of functionality (distribution and technology independent)

An object model of the system describing the structure of processing in terms of:

Computational objects

Interfaces (of computational objects): functions supported

Invocations (by computational objects): functions invoked

Computational bindings

Environment contracts (e.g., QoS constraints)


BIS – Computational specification

Objects in a computational specification can be application objects (e.g. a bank branch) or ODP infrastructure objects (e.g. a type repository or a trader)

Objects interact at well defined interfaces, using signals,

operations or flows.BankTeller = Interface Type {

operation Deposit (c: Customer, a: Account, d: Dollars)

returns OK (new_balance: Dollars)

returns Error (reason: Text);

operation Withdraw (c: Customer, a: Account, d: Dollars)

returns OK (new_balance: Dollars)

returns NotToday (today: Dollars, daily_limit: Dollars)

returns Error (reason: Text);

}

17


BIS – Computational specification

Interfaces allow subtyping

Environment contracts capture non functional requirements

Security,

performance,

availability,

etc.


The engineering specification

Specifies the mechanisms and services that provide the distribution transparencies and QoS constraints required by the system, independent of platform and technology

An object model of the system describing the infrastructure supporting the computational structure

Basic engineering objects

(Infrastructure) Engineering objects

Clusters, capsules, nodes

Channels

Functions

Highly dependent on the CVBEOs correspond to comp. objects

Channels correspond to Bindingobjects

18


Grouping concepts


Channel structure

19


Multi-endpoint channel


The technology specification

Specifies the H/W and S/W pieces from which the system is built

An object model of the system

defining the configuration of technology objects that comprise the ODP system, and the interfaces between them

identifying conformance points

20


BIS – Technology specification

Technology object types

Types of PCs, servers, ATMs, printers

Types of Operating Systems and Applications (text editors, etc)

Types of connections (LANs, WANs, Intranets, etc.)

Technology selection process

Providers’ selection and contracts

Conformance points

Compliance tests

Implementation, deployment, maintenance, evolution

Deployment plans

Configuration guides

Evolution plans


ODP Correspondences, Common Functions and Transparencies

CorrespondencesAn ODP specification of a system is composed of five views and a set of correspondences between them

Correspondences do not belong to any view

ODP distinguishes two kinds of correspondencesRequired correspondences

Correspondence statements

Common functionsAn ODP specification can make use of some of the common functions defined by the RM-ODP. They are “standard”

TransparenciesAn ODP specification can implement some of the transparencies defined by the RM-ODP

The specification should state which ones are used, and how they are implemented

Documents

ViewpointModelingcanal/sabc/ViewpointModeling.pdf · ODS, Enterprise Architecture, Viewpoints, Models 3. Modeling approaches and standards •IEEE Std 1471 •Krutchen’s4+1 model