LTP Port and Spec enhancements for “2.0”

Slides:



Advertisements
Similar presentations
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
Advertisements

Lecture # 2 : Process Models
The Architecture Design Process
UML CASE Tool. ABSTRACT Domain analysis enables identifying families of applications and capturing their terminology in order to assist and guide system.
Common Mechanisms in UML
Introduction to Software Design Chapter 1. Chapter 1: Introduction to Software Design2 Chapter Objectives To become familiar with the software challenge.
UML Class Diagrams: Basic Concepts. Objects –The purpose of class modeling is to describe objects. –An object is a concept, abstraction or thing that.
Business Modeling : basic concepts Extracted from Rational UML Profile for business modeling.mht.
An Introduction to Software Architecture
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
R McFadyen Chapter 7 Conceptual Data Modeling.
Component frameworks Roy Kensmil. Historical trens in software development. ABSTRACT INTERACTIONS COMPONENT BUS COMPONENT GLUE THIRD-PARTY BINDING.
Modeling Component-based Software Systems with UML 2.0 George T. Edwards Jaiganesh Balasubramanian Arvind S. Krishna Vanderbilt University Nashville, TN.
® A Proposed UML Profile For EXPRESS David Price Seattle ISO STEP Meeting October 2004.
Chapter 5 System Modeling. What is System modeling? System modeling is the process of developing abstract models of a system, with each model presenting.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
Object-Oriented Software Engineering Practical Software Development using UML and Java Modelling with Classes.
Integrating BPMN and SoaML Based on an example from SoaML spec.
Chapter 11: Abstract Data Types Lecture # 17. Chapter 11 Topics The Concept of Abstraction Advantages of Abstract Data Types Design Issues for Abstract.
1 Team Skill 3 Defining the System Part 1: Use Case Modeling Noureddine Abbadeni Al-Ain University of Science and Technology College of Engineering and.
Task 1 Scope – Controller (L=ND)
UML Diagrams By Daniel Damaris Novarianto S..
Roberta Roth, Alan Dennis, and Barbara Haley Wixom
Evolution of UML.
CS 389 – Software Engineering
Course Outcomes of Object Oriented Modeling Design (17630,C604)
Software Processes (a)
ONF Specification Class Pattern Some items for discussion
Entity-Relationship Modeling
Update Nigel Davis (Ciena).
Level 1 Level 1 – Initial: The software process is characterized as ad hoc and occasionally even chaotic. Few processes are defined, and success depends.
Chapter 2 – Software Processes
KEY PRINCIPLES OF THINKING SYSTEMICALLY
Chapter 9 Requirements Modeling: Scenario-Based Methods
UML Class Diagrams: Basic Concepts
Chapter 2 Software Processes
IMAT5205 Systems Analysis and Design
Introduction to the Unified Modeling Language
Chapter 20 Object-Oriented Analysis and Design
Design and Implementation
Verification Concepts for SysmL v2
An Introduction to Software Architecture
Photonics in ONF Core and TAPI
ONF OTCC TAPI Contribution
Photonic model Nigel Davis (Ciena)
Methodology Conceptual Databases Design
CHAPTER 2 - Database Requirements and ER Modeling
Design Yaodong Bi.
Verification Concepts for SysmL v2
Web-based Imaging Management System Working Group - WIMS
TAPI Topology & Connectivity Enhancements Proposal for v3.0
Discussion with OASIS TOSCA
Service-Resource-Capability and Intent (stimulated by discussion on TAPI Virtual Network) Nigel Davis
UML  UML stands for Unified Modeling Language. It is a standard which is mainly used for creating object- oriented, meaningful documentation models for.
Various notes for use in “Controller, Processing Construct and Component” discussions at CORD Build face to face Nigel Davis
Profiles and Templates
Task 34 Scope – LTP Port (L=Nigel Davis)
ONF CoreModel Profile & Template model
Spec model application
Extending and Refining the OTCC/OIMT Models
Task 2a Scope – Processing Construct (L=ChrisH)
Photonic model Nigel Davis (Ciena)
Task 34 Scope – LTP Port (L=Nigel Davis)
Topology and FC properties
Control for 1.4 Nigel Davis (Ciena)
LTP Port and Spec enhancements for “2.0” Preparing to make the change
Intent for use of capability replaces Service-Resource and unifies network and virtual network (stimulated by discussion on TAPI Virtual Network) Nigel.
Catalog driven APIs & Operations Patterns
Drawing from TR Nigel Davis
See also (oimt2018.ND.034.xx_SpecModelApplication..)
Presentation transcript:

LTP Port and Spec enhancements for “2.0” Nigel Davis (Ciena) 20180614

Adding port to LTP The LTP represents the effects of functionality related to termination and adaptation of signal protocols The functionality represented by the LTP is of significant variety and complexity It encapsulates/abstracts that complexity and exposes the effects via its attributes and associations (as do all classes that represent functionality) The effect of the functionality encapsulated is described in the LTP Spec (currently to a limited degree) The LTP spec is a degenerate description system The system described is an abstraction of the complex system actually realizing the LTP The description is intended to be sufficient to allow full understand of the capability and to interpret the visible controls and visible effects (attributes) A description system (I need a better name for this) is equivalent to the functional schematic of an integrated circuit in that it explains the arrangement of meaningful macro-functions but does not describe the actual underlying system The properties of the LPs that the LTP is composed of provide the dynamic values to be understood in terms of the specific invariant spec for the LTP The LTP model is a degenerate form of the Component-Port pattern where associations are used to express port role The absence of the port complicates the model and makes full specification more awkward …

Component-Port Pattern Component-System Pattern Rule Patterns Recap with comments in red

Component-Port pattern Most of the associations on this diagram should be to LtpPort The current model has many cases of Component-Port where the Port provides access to the capability of the Component The Components considered are functional (but the same pattern applies to physical things) All Components are asymmetric in nature such that different capability is exposed at different Ports (such that the Ports essentially have roles in the context of the apparent internal structure of the Component) In some narrow cases we can ignore the asymmetry and fold the Ports away TMF IG1118 distinguished between four very distinct Port types where the most “interesting” currently are Operations and Application We need to continue to develop this area

Component-System Patterns LTP is a component with ports It is described in terms of a system of Components LPs, TerminationSpecs etc Some of the ports on spec components are SystemBoundaryPorts and hence Ports on the LTP The Component-System pattern appears to underpin all models of capability The System is NOT simply: An aggregation, a collection, of bits in a bag A UML Composition which allows from no more than an owned collection The System is an assembly of interconnected Components where the specific interconnection is critical consideration The Component is a bounded context which exposes underlying capability via its Ports Not shown here… the Capability of a Component can be represented in the form of an apparent System We should continue to develop this area

Component-System Pattern – Refactoring We currently appear to use several different refactorings of the Component-System pattern The figures show two progressions from the full pattern to the most basic form Further figures that show how the capabilities are exposed may help explain the pattern Remove SystemBoundaryPort Remove System Remove Port Remove Port Remove System The LTP uses the most degenerate form but is associated to from parts of the model that use ports… so the overall model is a hybrid of refactoring degrees

Strengthening the Component-Port This provides a sketch of the LTP and LP ports The LTP is a Component that is a System of Components, LPs. The LTP and LP ports are not exposed directly There appear to be several cases that would benefit from LTP/LP port exposure However, exposure of a generalized Port appear to complicate the model It is proposed that: The LTP class and the LP class have LtpPort and LpPort added The Spec model be enhanced to deal with ports Changes to add Ports be considered as a 2.0 release considering the significance of the change We work to make 1.n and 2.n compatible 

Rule Patterns As shown, but not discussed, in the previous slides Associations are interrelated In the Class model the associations appear to form loops but in some cases in the instance models these are Loops, but in other cases they are Spirals. Some of the Spirals are LockStep so as one go instance Spiral progresses, so does another The association instances are represented via attributes and it is these attributes that that are constrained Some constraints are influenced by other attributes that are not explicit representatives of associations Raw UML is silent in this area of complexity The only UML mechanism that appears to allow the necessary capability/access is the Constraint Constraints represented in OCL has been shown to be complex and OCL is a very narrow specialist area Alternative constraint languages may be less opaque but stating that patterns per case is complex and error prone It is proposed that a “DSL” of labelled Constraint patterns be developed and that these drive OCL etc

LTP with ports New model sketch

First cut LTP with Port (showing primary context) Note that the view mapping function should describe the inter-view relationship.

Expressing Capability and Needs Pruning and Refactoring Recap

Unification It is assumed that expression of Capability and of Need can be of the same form The focus here will be on Capability Currently, capability is expressed via specific spec structures, one for each the key class, LTP, FC etc., in the model A spec may include several cases of use of one of the spec elements In addition, there are scheme/system specs that express the capability of systems of key classes But considering, from a fundamental perspective, the arbitrary position of the class boundary, it would seem to be the case that system specs and key class spec should be of the same structure and hence the structure should be unified It would seem that the Component-System pattern should be a basis for the unified structure

Class to spec to instance Spec for class X Spec case S of class X Instance 1 of case S of class X P&R Part Type A Part Type B Part Type A.c Part Type B.w Part Type A. (c) Part Type B.1 (w) Part Type A.d Part Type B.y Part Type A.1 (d) Part Type B.1 (y) The spec pattern is expanded for each case to have the necessary occurences of each part, interconnected within the constraints of the Spec structure The Spec case is then instantiated for each occurrence of the case Instance 2 of case S of class X Part Type A.2 (c) Part Type B.2 (w) Part Type A.2 (d) Part Type B.2 (y)

Further thoughts The detailed capability of a thing is expressed by decorating with parts that themselves have constrained semantics that fit within the definition of the thing The capabilities may be expressed in terms of apparent subordinate parts where these parts can be positioned on the constrained semantic map An LTP may have controllers within it but those controllers only emerges when the LTP is dismantled or its behaviour is expressed.

Spec approach Defines the decoration that details, for a particular case, part of the semantic space covered by the class This allows for a dynamic extension (and reduction) of exposed capability which interplays with intent The scheme spec describes a system structure in terms of classes of the model and in terms of constraints The same grammar for systems of constraints would appear to apply here The scheme spec provides the constraints on what outcomes can be requested

But… An approach is to develop a generalized Component spec using the Component-System pattern where a particular usage is developed by P&R of the pattern to give necessary constrained parts This method would allow the generation of a scheme/system spec structure and an LTP spec structure But as noted earlier, the LTP can be derived from the Component- System pattern by appropriate application of P&R The challenge is what are the classes and what are the constraints, or, as noted earlier, can we simply consider a class as a representation of constraints

Proposal Construct a generalized Component-System spec Apply this via repeated P&R to yield a refined LTP and System/Scheme spec etc In the process, loosen the LTP/LP spec to support photonics Part of this needs to be done in 1.4.n/1.5.n to enable description of the Photonic network LTPs etc but there will need to be further work in 2.0 to fully rationalize this and to deal with LtpPort and LpPort Explore restarting the P&R tooling and use of it to assist this work, especially in the 2.0 time frame.

LTP spec considerations

Current LTP Spec for 1.4 and 2.n The Diagram shows the 1.3.1 spec For photonics in 1.4 we need to add an “FC” to the LTP spec instead of the Connection Spec This will need ports and its own spec It appears that LP recursion and Termination recursion would make sense Adding ports and recursion sufficiently is essentially applying the Component-System pattern In 2.n it is probably valuable to refactor the LTP spec to be a full generalized Component-System spec with constraints on what components can be used.

Questions? Thank you 