Viewpoint Modeling Antonio Vallecillo Universidad de Málaga Dpto. Lenguajes y Ciencias de la Computación av@lcc.uma.es http://www.lcc.uma.es/~av Master en Ingeniería del Software e Inteligencia Artificial 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 1
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 3 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 shops Include several POS in a shop, shop servers, business server, warehouse computers, connection to financial services (banks, credit cards), suppliers, etc. Process farms SETI@home, folding@home P2P systems (Napster), Emule, KaZaA Avionics and space systems Large and heterogeneous systems, many participants, many kinds of devices, embedded computers, critical operations 4 2
A system is open if its specifications are available Open systems 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 5 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 6 3
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.) 7 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 8 4
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 softwareintensive 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. 9 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 a view and the techniques for its creation and analysis. 10 5
IEEE 1471 conceptual model of architectural description 11 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 by a) 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 12 6
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 13 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) 14 7
Krutchen s 4+1 view model 15 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 16 8
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) 17 Zachman s framework 18 9
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 19 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 comprises A structure for system specifications in terms of viewpoints A set of object-oriented foundation modeling concepts common 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 20 10
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) 21 ODP Viewpoints different concerns Enterprise Information System Computational Technology Engineering 22 11
An ODP system specification - business aspects - What for? Why? Who? When? - information - changes to information - constraints - Object configuration - Interactions between objects at interfaces - Mechanisms and services for distribution transparencies and QoS constraints. - Hardware and software components implementing the system Enterprise Information Computational Engineering Technology - and correspondences between specifications 23 ODP Correspondences Enterprise Information Computational Engineering Technology 24 12
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 Behaviour Roles (fulfilled by enterprise objects in a community) Processes (leading to Objectives) Policies Accountability The system is just another object 25 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 ISrelated issues 26 13
BIS Enterprise specification Each branch, and will be specified by a community Its 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 present some ID for withdrawing money. Authorizations: accounts of some VIP customers are allowed to have overdrawn. 27 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 28 14
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 29 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. 30 15
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) 31 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); } 32 16
BIS Computational specification Interfaces allow subtyping Environment contracts capture non functional requirements Security, performance, availability, etc. 33 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 CV BEOs correspond to comp. objects Channels correspond to Binding objects 34 17
Grouping concepts 35 Channel structure 36 18
Multi-endpoint channel 37 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 38 19
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 39 ODP Correspondences, Common Functions and Transparencies Correspondences An 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 correspondences Required correspondences Correspondence statements Common functions An ODP specification can make use of some of the common functions defined by the RM-ODP. They are standard Transparencies An 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 40 20