© Ingo Arnold Advanced Software Engineering Duale Hochschule Baden-Württemberg View Models Introduction – Views and Perspectives

View Models Overview Duale Hochschule Baden-Württemberg – Advanced Software-Engineering 2  Levels are like different zooms. The observed object remains the same – it’s the level of detail which varies

View Models Overview Duale Hochschule Baden-Württemberg – Advanced Software-Engineering 3  Views are like filters, which ignore (on a given zoom-level) certain aspects while exclusively focussing others

View Models Levels Duale Hochschule Baden-Württemberg – Advanced Software-Engineering 4  Systems can be analyzed, described and understood on different levels of abstraction (Architecture Levels).  On Architecture Levels the according architectural decisions are taken as well as appropriate artefacts would be positioned.  An Architect should always be well aware of the Architec- ture Level that he acts upon.

View Models Levels Duale Hochschule Baden-Württemberg – Advanced Software-Engineering 5 earthcountry region town house your place

View Models Levels Duale Hochschule Baden-Württemberg – Advanced Software-Engineering 6 System Level Building- block Level Organisation Level  On a high-level three major levels can be distinguished

View Models Levels Duale Hochschule Baden-Württemberg – Advanced Software-Engineering 7  Organisation Level Examples Data-exchange protocol between IT-Systems is SQLNet Enterprise canonical data-format defines data exchange format Remoting protocol for functional invocations is IIOP All IT-Systems have to be documented according to guideline X Data-exchange communication style must be asynchronous based on corporate MOM infrastructure Corporate development process is mandated for life-cycle mana- gement of all IT-Systems Corporate roles must be mapped to IT-Systems’ actors

View Models Levels Duale Hochschule Baden-Württemberg – Advanced Software-Engineering 8  System Level Examples Data-exchange protocol between Building-blocks is serialized Java IT-System canonical data-format defines data exchange format that must be used between Building-blocks Remoting protocol for functional invocations across Building- blocks is Java-RMI All Building-blocks have to be documented according to JavaDoc standard Data-exchange communication style between Building-blocks can be either synchronous (for strongly coupled Building-blocks) or asynchronous (for loosely coupled Building-blocks) Building-blocks’ roles must be tracable to corporate roles

View Models Levels Duale Hochschule Baden-Württemberg – Advanced Software-Engineering 9  Building-block Level Examples All inter-class communication is abstracted via Java-Interfaces Programming environment Java for business logic Building-blocks, ASP.NET for all web-facing Building-blocks Inter-thread communication via thread-safe data-objects Code-level documentation standard to follow is XDocLet JAAS-standards to follow for implementation of security model

View Models Levels Duale Hochschule Baden-Württemberg – Advanced Software-Engineering 10  Nota bene – places can sometimes be houses! What is this?

View Models Views Duale Hochschule Baden-Württemberg – Advanced Software-Engineering 11  It‘s difficult to cover all aspects of a given IT-System with a singular view  Not all aspects are always relevant  Architecture views help the architect to reduce the number of aspects made visible at a given moment in time  Architecture Levels are an organisational tool – views make architecture tangible  Architecture models like Zachman or Togaf use the con- cept of Levels to orderly arrange and frame views.

View Models Views Duale Hochschule Baden-Württemberg – Advanced Software-Engineering 12  Such models also describe how views have to be used in conjunction in order to provide overviews tailored to ap- propriate stakeholders  The view concept is used to express actual content and show the aspect of current interest of a given whole  Complementary views are organized within Architecture Models (e.g. Zachmann, TOGAF)  Architecture views help to gain architectural completeness with regards to a given aspect  Typically Architecture views are incrementally developed

View Models Views Duale Hochschule Baden-Württemberg – Advanced Software-Engineering 13  Examples of aspects that can be observed within views Logical building-blocks Physical building-blocks Deployment of building-blocks to operational nodes Security Physical infrastructure Locations and data-centres IT-System interdependencies Datapaths System-Management components

View Models Views Duale Hochschule Baden-Württemberg – Advanced Software-Engineering 14  A complete set of views should address the following aspects Architectural context Architectural building blocks as well as the relationship amongst these Relationships between views Process of developing a specific view for a given IT-System  Ideally Architecture views are disjunct and loosly coupled

View Models Views Duale Hochschule Baden-Württemberg – Advanced Software-Engineering 15  An IT-System‘s architectural description is the sum of all architecture views – thus it is multi-dimensional

View Models Views Duale Hochschule Baden-Württemberg – Advanced Software-Engineering 16  Views in the context of Levels and Stakeholders

View Models Views Duale Hochschule Baden-Württemberg – Advanced Software-Engineering 17  How UML et al relates to views Class diagrams model static structure of a system Class diagrams can be used to sketch business concepts as well as to express class-level designs You need to always understand view-point, first. The fact that a class-diagram was used doesn’t tell you on which abstraction level you are Business concepts IT-System Design

View Models Views Duale Hochschule Baden-Württemberg – Advanced Software-Engineering 18  How UML et al relates to views

View Models Duale Hochschule Baden-Württemberg – Advanced Software-Engineering 19  View Models are generally comprised of... Form Method & Process Tool Content

View Models Duale Hochschule Baden-Württemberg – Advanced Software-Engineering 20  View Models are generally comprised of... Form determines what to describe and capture  views and element types Method & Process determine why and how to capture  check-lists and cookbooks Tool determines whereby to capture  repository management, notions and reporting Content is what was actually captured  objects of element types

View Models Duale Hochschule Baden-Württemberg – Advanced Software-Engineering 21  View Models MOTIVATIONDATAFUNCTIONNETWORK SCOPE BUSINESS APPLICATION TECHNOLOGY List of business goals / strategies List of things important to the business List of processes the business performs List of locations in which the business operates Business PlanE.g. Semantic Model Ent.: Business Entity Rel.: Business Relationship E.g. Business Process Model Proc.: Business Process IO: Business Resources E.g. Business Logistics Model Node: Business Location Link: Business Relation Business Rule ModelE.g. Logical Data Model Ent.: Data Entity Rel.: Data Relationship E.g. Application Architecture Proc.: Application Function IO: User Views E.g. Distributed Systems Architecture Node: S-Function Link: Line characteristics Rule DesignE.g. Physical Data Model Ent.: Database / Table Rel.: Phys. Relationships E.g. System Design Proc.: Program Function IO: Data Elements, IFs. E.g. HW-Technology Architecture Node: HW system Link: Line Specification View - Filter View - Level

View Models Duale Hochschule Baden-Württemberg – Advanced Software-Engineering 22  View Models MOTIVATIONDATAFUNCTIONNETWORK SCOPE BUSINESS APPLICATION TECHNOLOGY List of business goals / strategies List of things important to the business List of processes the business performs List of locations in which the business operates Business PlanE.g. Semantic Model Ent.: Business Entity Rel.: Business Relationship E.g. Business Process Model Proc.: Business Process IO: Business Resources E.g. Business Logistics Model Node: Business Location Link: Business Relation Business Rule ModelE.g. Logical Data Model Ent.: Data Entity Rel.: Data Relationship E.g. Application Architecture Proc.: Application Function IO: User Views E.g. Distributed Systems Architecture Node: S-Function Link: Line characteristics Rule DesignE.g. Physical Data Model Ent.: Database / Table Rel.: Phys. Relationships E.g. System Design Proc.: Program Function IO: Data Elements, IFs. E.g. HW-Technology Architecture Node: HW system Link: Line Specification View - Filter View - Level

Questions? Duale Hochschule Baden-Württemberg – Advanced Software-Engineering 23