Use ER-Assistant or draw.io to answer the question
Modelers from multiple organizations can work on multiple Model-Based Systems Engineering (MBSE) models. SMCT provides some very simplistic support. A model has an unique model Id, a name, an optional description, and a start date. A model is composed of one or more top level assets. An asset can be a SysML (similar to UML) model diagram. For examples, model P may contain 2 top level class diagrams, 1 package diagram and 2 sequence diagrams. Thus, an asset has a predefined type, e.g. 'Class Diagram', 'Package Diagram', 'Class Diagram', etc, An asset has an unique Ald, a name, and a description. An asset may be a part of another asset. For examples, class diagram A may have three subclass diagrams: B, C, and D. An asset may have some relationships with other assets, and the descriptions of these relationships should be stored. For examples, asset P may have a relationship of 'provides implementation support to' asset Q, and a relationship of 'has a pro-con-add-up relationship with asset R. Since models evolve, an asset may have many versions. We may call a version of an asset an item. For example, the asset P may have three versions 1. Version 1.0: start time: 12:05:11; 01/07/2019 2. Version 1.2: start time: 08:15:22; 04/18/2019 3. Version 2.0: start time: 10:28:31; 07/09/2019 An item can be stored in one or more (as duplicate copies of) files. A file F has a path (e.g. 'c:\user\yue \doc\soso') and a name (e.g. 'p1.mdzip'). A file locates in a file system. A file system has an unique id, a name, and a description (e.g. for FS1: 101, "UHCL-DCM-Server-11', 'DCM Window Server #11 for support of CSCI 4333'). A file system has a predefined type (e.g. for FSI: 'Windows 10 Server') Other examples of file system types: 'Linux', 'Cloud', 'IPFS, etc'. For examples, for asset P, 1. Version 1.0 may be stored in 1. File System FS1 as c:\user\yue \doc\soso\p_v1_0.mdzip 2. File System FS1 as c:\user\yue\doc\haha amed_p1.mdzip 3. File System FS8 as \temp\temp_p1.mdzip 2. Version 1.2 may be stored in 1. File System FS1 as c:\user\yue\doc\soso\p_v1_2.mdzip 2. . Modelers work on models. An unique modelerid, a last name, a first name, a phone, and an email should be stored for every modeler. A modeler is an employee of an organization. For an organization, an unique id, a name, and an email should be stored. Every model must have a lead organization, and zero or more collaborating organizations. A model has a modeler to serve as its lead modeler. A model may have many collaborating modelers beyond the lead modeler. A description of the role of a modeler in a model should be recorded. For example, model P may have three modelers beyond the lead modeler collaborating on it with the following roles: 1. Modeler X: Chief Interim Vice Modeler' 2. Modeler Y: 'Just hanging around to get credit' 3. Modeler Z: 'the intern who actually does everything' An item may need approval. There are various predefined approval status, e.g. 'initial', 'level 1 approved', 'level 2 approved', etc. When an item is approved, the approval time, an optional comment, and the approver (a modeler) is noted. An item can be approved several times (e.g. first with the status 'initial', then 'level 1 approved', and then 'level 2 approved'). All approval history is stored. Modelers from multiple organizations can work on multiple Model-Based Systems Engineering (MBSE) models. SMCT provides some very simplistic support. A model has an unique model Id, a name, an optional description, and a start date. A model is composed of one or more top level assets. An asset can be a SysML (similar to UML) model diagram. For examples, model P may contain 2 top level class diagrams, 1 package diagram and 2 sequence diagrams. Thus, an asset has a predefined type, e.g. 'Class Diagram', 'Package Diagram', 'Class Diagram', etc, An asset has an unique Ald, a name, and a description. An asset may be a part of another asset. For examples, class diagram A may have three subclass diagrams: B, C, and D. An asset may have some relationships with other assets, and the descriptions of these relationships should be stored. For examples, asset P may have a relationship of 'provides implementation support to' asset Q, and a relationship of 'has a pro-con-add-up relationship with asset R. Since models evolve, an asset may have many versions. We may call a version of an asset an item. For example, the asset P may have three versions 1. Version 1.0: start time: 12:05:11; 01/07/2019 2. Version 1.2: start time: 08:15:22; 04/18/2019 3. Version 2.0: start time: 10:28:31; 07/09/2019 An item can be stored in one or more (as duplicate copies of) files. A file F has a path (e.g. 'c:\user\yue \doc\soso') and a name (e.g. 'p1.mdzip'). A file locates in a file system. A file system has an unique id, a name, and a description (e.g. for FS1: 101, "UHCL-DCM-Server-11', 'DCM Window Server #11 for support of CSCI 4333'). A file system has a predefined type (e.g. for FSI: 'Windows 10 Server') Other examples of file system types: 'Linux', 'Cloud', 'IPFS, etc'. For examples, for asset P, 1. Version 1.0 may be stored in 1. File System FS1 as c:\user\yue \doc\soso\p_v1_0.mdzip 2. File System FS1 as c:\user\yue\doc\haha amed_p1.mdzip 3. File System FS8 as \temp\temp_p1.mdzip 2. Version 1.2 may be stored in 1. File System FS1 as c:\user\yue\doc\soso\p_v1_2.mdzip 2. . Modelers work on models. An unique modelerid, a last name, a first name, a phone, and an email should be stored for every modeler. A modeler is an employee of an organization. For an organization, an unique id, a name, and an email should be stored. Every model must have a lead organization, and zero or more collaborating organizations. A model has a modeler to serve as its lead modeler. A model may have many collaborating modelers beyond the lead modeler. A description of the role of a modeler in a model should be recorded. For example, model P may have three modelers beyond the lead modeler collaborating on it with the following roles: 1. Modeler X: Chief Interim Vice Modeler' 2. Modeler Y: 'Just hanging around to get credit' 3. Modeler Z: 'the intern who actually does everything' An item may need approval. There are various predefined approval status, e.g. 'initial', 'level 1 approved', 'level 2 approved', etc. When an item is approved, the approval time, an optional comment, and the approver (a modeler) is noted. An item can be approved several times (e.g. first with the status 'initial', then 'level 1 approved', and then 'level 2 approved'). All approval history is stored
