7/29/2019 Lecture #3c
1/50
SYS 5390 Lecture #3, Slide 1
Model BasedCollaborative Systems Engineering
Stphane Bucaille, PhDElectrical and Computer Engineering Department
7/29/2019 Lecture #3c
2/50
SYS 5390 Lecture #3, Slide 2
MBSEProcess
remainder
SysMLlanguagearchitecture
Modelingstructurewithpackage
7/29/2019 Lecture #3c
3/50
SYS 5390 Lecture #3, Slide 3
7/29/2019 Lecture #3c
4/50
SYS 5390 Lecture #3, Slide 4
MBSE Overview
Context
MBSE: A myth or reality?
MBSE Benefits MBSE Implementation Challenges
MBSE process example
Conclusions
7/29/2019 Lecture #3c
5/50
SYS 5390 Lecture #3, Slide 5
Context Systems increasing complexity Program over-costs and delays continuously
increase as well Aeronautics:
Dreamliner: $9B, 3 years A380: $10B, 15 months
Energy: EPR: $4B, 5 years
Communications: Next Gen Data Comm: $4.2B, from 2 months to 14
years!
Reasons Technology development and development
dynamics Competition pressure Inability of traditional systems engineering
approach to tackle increasing complexities Hardware
Technologies Functions and Performance System Architectures and Interfaces
Software Functions and capabilities Implementation techniques Cyber-security challenges
Organizations Stakeholders Skills Processes and Tools Knowledge management and reusability
Slide courtesy of MBSE4All, LLC
7/29/2019 Lecture #3c
6/50
SYS 5390 Lecture #3, Slide 6
Context
Growing need for systems affordability and resilience
This requires faster delivery of adaptable, trusted,
assured, reliable and interoperable systems
Slide courtesy of MBSE4All, LLC
7/29/2019 Lecture #3c
7/50SYS 5390 Lecture #3, Slide 7
MBSE: A myth or reality
Model-based systems engineering (MBSE) is the formalized
application of modelingto support system requirements, design,analysis, verification and validation activities beginning in theconceptual design phase and continuing throughout developmentand later life cycle phases.
INCOSE SE Vision 2020 (INCOSE-TP-2004-004-02, Sep 2007)
Slide courtesy of MBSE4All, LLC
7/29/2019 Lecture #3c
8/50SYS 5390 Lecture #3, Slide 8
MBSE: A myth or reality
One definition
Generic In support of systems engineering approaches
Only technical Definition does not mention any business objectives
Many valuable questions On changing core and development activities
Scope and reality of change (processes, skills, tools, organization) Buy-in by customers, partners, suppliers, and mostly internal teams!
On impact change On efficiency and competitiveness On flexibility and agility to develop and offer rapidly cost effective and
adaptable solutions
On transformation process
Where to start? How to deploy? How to measure implementation? At what cost and risk?
Slide courtesy of MBSE4All, LLC
7/29/2019 Lecture #3c
9/50SYS 5390 Lecture #3, Slide 9
MBSE: A myth or reality
So whyMBSE? Is it just a buzz word?
Why is it so deeply studied? worked out? utilized? National and international Bodies: OMG, INCOSE, NDIA,
NIST
Governmental agencies: DoD, NASA Aerospace and Defense industries: Lockheed Martin,
Northrop Grumman, General Dynamics, L3Communications
Energy (GE, AREVA, Alstom), Automotive (Ford)
Why is it becoming a standard for the complexsystems industry?
According to OMG, 28% of DoD contracts granted in2011were using MBSE approach
Strong synergies with DoDAF methodology
Slide courtesy of MBSE4All, LLC
7/29/2019 Lecture #3c
10/50SYS 5390 Lecture #3, Slide 10
MBSE: A myth or reality In fact, this reflects a reality
MBSE is the future of SE It combines traditional methods and best practices with rigorous modeling
techniques It uses modeling languages that support integration of various systems
engineering disciplines and stakeholders
Benefits demonstrated when methodology properly implemented Kyocera Mita: 80 percent of design errors detected prior to production,
leading to subsequent reduction in overall cost, while new product
development time reduced by 30 percent (source: IBM) Proper implementation of MBSE lead to cut development costs by 50% andreduce time to market by 45% (source: IMTI 2009)
MBSE implementation is challenging many aspects of a corporation The methodology is not unique nor universal
It does not replace SE, it formalizes part of it It is a framework and encompasses at least 5 different approaches Thus, it can or should be adapted/customized to any company
MBSE purely offers design processes, tools and SysML language, butproper implementation requires as well
Organization culture change, from document-based to model-based data trust Organization human resources diversification, appropriate training and support Organization/Projects management adaptation Organization transformation roadmap (Processes/IT/Structure)
Slide courtesy of MBSE4All, LLC
7/29/2019 Lecture #3c
11/50SYS 5390 Lecture #3, Slide 11
MBSE: a continuity in history
Rigor now required in the system design process As it is broadly in place for all other engineering
disciplines
Mechanical or Electrical Design An additional historical proof that shows how model-
based techniques enable and facilitate complexity
management
Slide courtesy of MBSE4All, LLC
7/29/2019 Lecture #3c
12/50SYS 5390 Lecture #3, Slide 12
Benefits
Enhanced Collaboration By the use of a
common languageand collaborativeplatform
Consistent,single sourceof information for the whole team
Improved quality Early identification of requirements/inconsistencies issues Enhanced system design integrity Improved specification of allocated requirements to HW/SW
(SysML Simulation) Fewer errors during I&T More rigorous requirements traceability
Increased productivity Improved impact analysis of requirements changes
Reuse of existing models to support design/technologyevolution
Auto-generation of up-to-date documentation
Reduced risk Improved cost estimates Early/on-going requirements validation & design
verification
Life Cycle Support
VerticalIntegration
Today: Standalone modelsrelated through documents
Future: Shared system model with multipleviews, and connected to discipline models
Slide courtesy of MBSE4All, LLC
7/29/2019 Lecture #3c
13/50SYS 5390 Lecture #3, Slide 13
MBSE Implementationchallenges
INCOSE MBSE Development Roadmap
Z
2010 2020 2025
Maturity
MBSE Capability
Ad Hoc MBSEDocument Centric
2010
WellDefinedMBSE
InstitutionalizedMBSE across
Academia/Industry
Reduced cycle times Design optimization across broad trade space
Cross domain effects based analysis
System of systems
interoperability
Extending Maturity and Capability
Distributed & secure model repositoriescrossing multiple domains
Defined MBSE theory, ontology, and formalisms
Emerging MBSE standards
Matured MBSE methods and metrics,Integrated System/HW/SW models
Architecture model integratedwith Simulation, Analysis, and Visualization
Planning & SupportResearchStandards DevelopmentProcesses, Practices, & Methods
Tools & TechnologyEnhancementsOutreach, Training & Education
Refer to activities inthe following areas:
Slide courtesy of MBSE4All, LLC
7/29/2019 Lecture #3c
14/50SYS 5390 Lecture #3, Slide 14
MBSE Implementationchallenges
Expertise creation Core Team of experts, per domains, possibly transversal to
organization Develop modeling standards, ontologies Build reusable repository, libraries Provide support to system model developers Pair experts with new hire to extend buy in of the methodology
Early support to ongoing projects Training 3 level training (Core Team, SE and Management, Everybody else)
Repartition of roles and responsibilities (BUs/Corporate) Who builds models for projects? Who interacts with specialized engineering teams?
Who provides modeling environment and infrastructure? Who develops repositories, standards, processes, ontologies?...
Roadmap defined and approved by executive management
Slide courtesy of MBSE4All, LLC
7/29/2019 Lecture #3c
15/50SYS 5390 Lecture #3, Slide 15
MBSE Implementationchallenges
Prepare project management and teams:
Impact on deliverables Use of automated reports Use of online reports Use of simulation tools
Impact on schedule, initially and thereafter Initially schedule time
to deploy infrastructure
to train workforce Once approach is implemented
take advantage of the methodology reusability benefits!
Impact on reviews Do not neglect hardware displays and communication technologies
Impact on metrics implements rigorous metrics
Quality of Design Progress of Design and Schedule aspects Estimated effort to complete design and development Financial aspects (COSYSMO model) Others (# of critical TBDs)
Slide courtesy of MBSE4All, LLC
7/29/2019 Lecture #3c
16/50SYS 5390 Lecture #3, Slide 16
MBSE ExampleGlobal Process
Slide courtesy of MBSE4All, LLC
7/29/2019 Lecture #3c
17/50SYS 5390 Lecture #3, Slide 17
PoleSat DiagramExamples
Scenario
Altitude( km) Orbi t
Inclination(deg)
Orbit
Period(s)
deltaL
(deg)
Time
in View(s)
Image
Width(km)
Field
of View(deg)
Number of
Pixelsin one
dimension
Number
of Pixelsin Image
Number of
PolePassages
Per Cycle
Number of
ImagesPer Cycle
Downlink
Data Volume(Bytes)
Downlink Data
Rate(bits/s)
1 600 97.87 5799 24 642 1133 87 801 642262 7 42 27096627 337651
2 700 98.28 5923 25 715 1157 79 818 669747 7 40 27088855 303038
3 800 98.70 6049 25 786 1181 73 835 697980 7 39 27083057 275777
4 900 99.13 6175 26 854 1206 68 853 726969 7 37 27079116 253610
5 1000 99.58 6303 26 921 1230 63 870 756720 7 36 27076925 235143
6 1100 100.04 6431 27 987 1255 59 887 787243 7 34 27076387 219464
7 1200 100.53 6560 27 1052 1279 56 905 818544 7 33 27077406 205945
Parametric
Diagram
Results inMS Excel
z
Slide courtesy of MBSE4All, LLC
7/29/2019 Lecture #3c
18/50SYS 5390 Lecture #3, Slide 18
7/29/2019 Lecture #3c
19/50SYS 5390 Lecture #3, Slide 19
The SysML Language
Specification (1/2)
Specifications published in September 2007
By the OMG Group In response to the requirement specified in the UML for SE RFP
Defines the SysML concepts An abstract syntax (schema, described by a metamodel)
A concrete syntax (notation, described using notation tables)
The semantics (meaning of the language concept in the SE domain)
7/29/2019 Lecture #3c
20/50
SYS 5390 Lecture #3, Slide 20
The SysML Language
Specification (2/2)
SysML organized in language units Model elements model-wide modeling concepts
Requirements textual requirements, and their relationships to
Each other
Models
Blocks system structure and properties
Activities extension to UML activities to support continuous behavior
Constraint blocks parametric models
Ports and flows extensions to UML to support
flow of information, matter,
energy between system elements
Allocations establish design relationships between model elements
7/29/2019 Lecture #3c
21/50
SYS 5390 Lecture #3, Slide 21
The SysML Language
Architecture
For the domain being modeled System Function
Domainconcepts
To language concepts Blocks Activities
Mapping ofDomainconcepts
Of the language concepts as they apply to aparticular system Block called airplane
Called user model
Instantiationand
representation
7/29/2019 Lecture #3c
22/50
SYS 5390 Lecture #3, Slide 22
The Modeling Domain
Objective: enable the description of some domain of interest
For SysML, domain of interest is the modeling of systems Domain concepts defined in the UML for SE RFP specifications
Requirements organized into concepts needed to model Structure, Behavior, Properties, Requirements, other systems modeling constructs
Ex: 6.5.1.1 System hierarchy. UML for SE shall provide to model the hierarchical
decomposition of a system into lower-level logical or physical components
Bills plane: a typical system
7/29/2019 Lecture #3c
23/50
SYS 5390 Lecture #3, Slide 23
The Modeling Language
(Metamodel) (1/2)
Describes the concepts in the language, their characteristics and
interrelationships It is the abstract syntax
Individual concepts are described by metaclasses Related to each other using relationships such as generalizations or associations
With set of properties that characterize the language concept it represents
And with a set of constraints that impose rules on the values for those properties
7/29/2019 Lecture #3c
24/50
SYS 5390 Lecture #3, Slide 24
The Modeling Language
(Metamodel) (2/2)
Profile: in UML, it is a mechanism used to customize UML language
Contains stereotypes, similar to metaclasses and used to create new or modifiedconcepts. (used for the extension of UML in SysML)
Figure shows two SysML concepts in the Blockslanguage unit of the SysML profile
And how they relate to UML metaclasses
Blockextends Class. It is the fundamentalstructural concept in SysML
Value Type extends Data Type. It addsquantitative features (unit, dimension)
Semantics: describe the meaning of its concepts in the domain ofinterest.
Described via mapping between the Domain concepts and the language concepts
The domain concepts defined either in natural language or mathematical form.
7/29/2019 Lecture #3c
25/50
SYS 5390 Lecture #3, Slide 25
The System Model
(User Model) (1/2)
Consists ofmodel elements that are instances of the metaclasses in
the SysML metamodel. A SysML Block may be instancied as an airplane, a fuselage, a wing and a landing
gear
The model elements are represented in this model conformed to the metaclassproperties, constraints, and relationships defined by the metamodel
These model elements are visualized using a concrete syntax mapped to the
abstract syntax so that each symbol represents a specific concept
7/29/2019 Lecture #3c
26/50
SYS 5390 Lecture #3, Slide 26
SysML Diagrams
In addition to a metamodel, SysML defines a notation (concrete
syntax)
SysMLDiagram
BehaviorDiagrams
ActivityDiagram
SequenceDiagram
StateMachineDiagram
Use CaseDiagram
RequirementDiagram
StructureDiagrams
BlockDefinitionDiagram
Internal BlockDiagram
ParametricDiagram
PackageDiagram
Same as UML Modified from UML Not in UML
7/29/2019 Lecture #3c
27/50
SYS 5390 Lecture #3, Slide 27
Diagram Frames
Diagram frames provide a visible context tor the diagram Certain diagrams explicitly draw symbols on or to the frame boundary to indicate
external interfaces of the model element represented by the diagram frame
Diagram Frame: rectangle with a header, or label, containingstandard information on the top left corner. The rest of the rectangle is the content area
An optional diagram description can be attached to the frame boundary.
7/29/2019 Lecture #3c
28/50
SYS 5390 Lecture #3, Slide 28
Diagram Header (1/4)
Diagram header(Label): rectangle with its lower right corner cut off.It includes: Diagram kind: abbreviation indicating the type of diagram
Model element type: type of model element that the diagram represents
Model element name: name of the represented model element
Diagram name: name of the diagram, usually to mention its purpose
Diagram usage: keyword indicating a specialized use of the diagram
Diagram kind: takes on of the following values Activity diagram - act
Block Definition Diagrambdd
Internal Block Diagramibd
Package Diagrampkg Parametric Diagrampar
Requirement Diagramreq
Sequence Diagramsd
State Machine Diagramstm
Use Case Diagramuc
7/29/2019 Lecture #3c
29/50
SYS 5390 Lecture #3, Slide 29
Diagram Header (2/4)
Model Element type: represented by the diagram kind. Validpermutations Activity diagram - activity
Block Definition Diagram block, constraint block, package, model, model library
Internal Block Diagram block
Package Diagram package, model, model library, profile, view
Parametric Diagram block, constraint block
Requirement Diagram package, model, model library, requirement
Sequence Diagram interaction
State Machine Diagram state machine
Use Case Diagram package, model, model library
Model element type needs to be included only when severalallowable model elements
7/29/2019 Lecture #3c
30/50
SYS 5390 Lecture #3, Slide 30
Diagram Header (3/4)
Diagram name: user defined, to provide a concise description of thediagrams purpose A model can contain considerable amounts of information
The modeler can choose to only represent
selected model elements
in a particular diagram
for a given purposeand hide other model elements from the diagram that may detract fromthis purpose
Diagram Usage: describes specialized use for the diagram type
Included in the header in guillemets Ex: the modeler can specify a context diagram as a usage of a use case diagram
Di H d
7/29/2019 Lecture #3c
31/50
SYS 5390 Lecture #3, Slide 31
Diagram Header
(4/4) (summary)
Diagram kind
Activity diagram - actBlock DefinitionDiagrambdd
Internal BlockDiagramibd
Package Diagrampkg
Parametric Diagrampar
Requirement DiagramreqSequence Diagramsd
State MachineDiagramstm
Use Case Diagramuc
Model element type
Activity diagram -activity
Block DefinitionDiagram block,constraint block,package, model,model library
Internal BlockDiagram block
Package Diagrampackage, model,model library, profile,view
Parametric Diagramblock, constraint block
Requirement Diagram package, model,model library,requirement
Sequence Diagraminteraction
State MachineDiagram statemachine
Use Case Diagrampackage, model,model library
Model element name
name of therepresented modelelement
Diagram name
user defined, toprovide a concisedescription of thediagrams purpose
Diagram usage
describes specializeduse for the diagramtype
7/29/2019 Lecture #3c
32/50
SYS 5390 Lecture #3, Slide 32
Diagram content (1/3)
Diagram content (canvas): contains elements that graphically
represent model elements 2 types of graphical elements
Node: symbol that contains text and/or other symbols to represent the internal detailof the represented elements
Paths: these edges are lines with multiple additional adornments such as arrows andtext strings
Possibility to hide information when not relevant
Properties and keywords A keyword identifies the type of model element (metaclass) to avoid any ambiguity.
included in guilletmets before the name of the model element
Symbols display commonly used information about their model elements in theirname string (name, type)
Properties: shown as a comma-separated list, enclosed in braces, following the nameof the model element
7/29/2019 Lecture #3c
33/50
SYS 5390 Lecture #3, Slide 33
Diagram content (2/3)
Node symbols Generally rectangular, or round-angles, ellipses
All nodes have
one name compartment (display the name string), with anyapplicable keyword(s) and properties
Eventually additional compartments used to display details ofnested elements
Path symbols Line with different styles and ends depending on the
modeling concept they represent
Optional text adornment that contains name string, keywords
or additional properties Eventually textual information on the ends where the
represented model element requires it
7/29/2019 Lecture #3c
34/50
SYS 5390 Lecture #3, Slide 34
Diagram content (3/3)
Icon symbols Typically used to represent low-level concepts that do not
have further internal details
Properties displayed in a text string floating near theobject
Note symbols
Can be attached to any model element or any set of model elements. Annotates the model with additional textual information (ex: hyperlink to a reference
document), called comment
Also used to display cross-cutting information, such as traceability torequirements and allocations
Displayed as a rectangular box with a cutoff upright corner
7/29/2019 Lecture #3c
35/50
SYS 5390 Lecture #3, Slide 35
Additional Notations
Table: Efficient and expressive way to represent information Requirements, interfaces information
Matrices: to describe relationships
Tree: hierarchical relationships presented using browser panels
7/29/2019 Lecture #3c
36/50
SYS 5390 Lecture #3, Slide 36
C t d
7/29/2019 Lecture #3c
37/50
SYS 5390 Lecture #3, Slide 37
Case study:
The Surveillance System
ACME Surveillance Inc., produces and
sells surveillance systems. Their range of surveillance systems
products is intended to provide securityeither for homes or small commercial sites
Their systems use sophisticated pan andtilt cameras to produce video images of the
surrounding area, and for a fee can beconnected to a central monitoring service.
ACME also produces the cameras andsells them as separate products for do-it-yourself enthusiasts.
Setup for a small commercial site: The system has 4 wall-mounted cameras (3 wired, 1 wireless)
1 of the offices is used to house the monitoring station
This station consists of one workstation and an additional screen
The office has a PBX that the monitoring station uses to communicate to itsdesignated command center
7/29/2019 Lecture #3c
38/50
SYS 5390 Lecture #3, Slide 38
Package Notions
Each model element has parents or contains Childs = hierarchy Packages = one example of container
The model elements contained in a package = packageable elements Blocks, use cases, activities
Member of a namespace: enables unique identification
A package is a namespace for the packageable element it contains
A model is a special type of package that contains a set of model elements thatdescribes a domain of interest
Effective model organization required to Facilitate reuse of model elements (model library)
Enable easy access and navigability among model elements
Support configuration management of the model
Exchange information with other tools
Specific partitioning is methodology dependant
Views and viewpoints used to visualize models according to multiple organizingprinciples
View: package used to show a particular perspective on the model (ex: performance orsecurity)
Viewpoint: represents a particular stakeholder perspective that specifies the contents of aview
Many relationships b/n packages : Import relationship
7/29/2019 Lecture #3c
39/50
SYS 5390 Lecture #3, Slide 39
7/29/2019 Lecture #3c
40/50
SYS 5390 Lecture #3, Slide 40
The Package Diagram
The model elements contained within a package can be shown on a packagediagram
Package type: type of package represented in the diagram (model, package,model library, view)
Package name: identifies the particular package that the frames represents
Diagram name: used to summarize the diagram purpose
Defining packages using a
7/29/2019 Lecture #3c
41/50
SYS 5390 Lecture #3, Slide 41
Defining packages using a
Package Diagram
Models organization = hierarchical tree (similar to Win Explorer)
Packages used to partition elements into coherent units with properties: Access control
Model navigation
Configuration management
Most used packages:
Package: container for other elements (copy/delete properties)
Packageable elements: include blocks, activities, value types, andpackages
Model: top-level package in a nested package hierarchy
Primary hierarchy based on the project needs
Model Library: package that is designated to contain reusable elements
View: provides additional perspectives on the model using alternativeorganizing principles (cf next slides)
Defining packages using a
7/29/2019 Lecture #3c
42/50
SYS 5390 Lecture #3, Slide 42
Defining packages using a
Package Diagram
Packages possibly linked with different relationship types
Packages represented by Folder symbols
The figure depicts the top-level packages within the corporate model of ACME
It contains:
Standard off-the-shelf components
Standard engineering definitions (ex: SI units) The company's products
Specific extensions to support more domain-specific notations and concepts
The elements can then be represented on SysML diagrams (structure, behavior,requirements)
Organizing a Package
7/29/2019 Lecture #3c
43/50
SYS 5390 Lecture #3, Slide 43
Organizing a Package
Hierarchy
Model organization crucial. It impacts
Reuse Access control
Navigation
Configuration management
Data exchange
of the development process
Model hierarchy should be based on a set of organizingprinciples
By system hierarchy (system, sub-system, componentlevels)
By process life cycle (requirement analysis, systemdesign)
By teams working on the project By the type of model elements (requirements, behavior,
structure)
By model elements that are likely to change together
By model libraries
By any other logical defined grouping
7/29/2019 Lecture #3c
44/50
SYS 5390 Lecture #3, Slide 44
Containment relationship
Containment relationship: relates parents to children within a package hierarchy.
Several levels of the hierarchy can be shown
2 symbol options
Product level here organized to show 2 product lines and requirements
Cameras package hierarchy organized by artifact type
Behavior, Structure, and Parametrics
Surveillance System package hierarchy is organized based on architecturalprinciples:
Logical architecture
Physical architecture
Use Case package
Packageable elements
7/29/2019 Lecture #3c
45/50
SYS 5390 Lecture #3, Slide 45
Packageable elements
on a package diagram
Packageable elements: represented by node symbols or icons
Word block to indicates element type
7/29/2019 Lecture #3c
46/50
SYS 5390 Lecture #3, Slide 46
Packages as Namespaces
Package
Contains packageable elements
Is a namespace for all named elements within it
Uniqueness rule: Each element of a particular element type within one packagemust have a unique name
BUT difficult to implement
Possibility to add the type keyword in the symbol (block)
Multi-hierarchy display induced confusion cleared by the use ofqualified names
Importing elements into
7/29/2019 Lecture #3c
47/50
SYS 5390 Lecture #3, Slide 47
Importing elements into
Packages (1/2)
Package import / element import
Used to clear potential ambiguity of previous diagram
Used to bring an element or collection of elements from one namespace toanother namespace
Elements modifiable only in the source namespace
Name clash rules apply
Named elements recognized within a namespace are called members
Public or Private visibility
Public allows import
Private only allows access
Importing elements into
7/29/2019 Lecture #3c
48/50
SYS 5390 Lecture #3, Slide 48
Importing elements into
Packages (2/2)
Import shown by a dashed arrow, labeled import or access, pointing to the source (packageor element)
Diagram description
Resulting packages and consequent naming
Dependencies between
7/29/2019 Lecture #3c
49/50
SYS 5390 Lecture #3, Slide 49
Dependencies between
packageable elements
Dependancy relationships: used when the content of one package is dependant on the
content of another package 5 more common types of dependencies
Use: the client uses the supplier as part of its definition
Refine: the client represents an increase in detail compared to the specification of thesupplier (usually in requirement analysis)
Realization: the client realizes the specification expressed in the description of the
supplier Trace: there is a linkage b/n the client and supplier without imposing more significant
semantic constraints
Allocate: one model element is allocated to another
7/29/2019 Lecture #3c
50/50
Views and Viewpoints Viewpoint: describes perspective of interest of a set of stakeholders that is used to specify a
view of a model. It includes the set of properties that identify
The purpose or reason for taking this perspective
The stakeholders who have an interest in this perspective
The concerns that the stakeholders wish to address
The languages used to present the view
The methods used to establish the view
View: Type of package thatconforms to a viewpoint
Imports set of model elementsaccording to the viewpointmethod
Conform relationship
Top Related