We consider the following concepts related to the file system of a hypothetical operating system (quasi-Linux): 1. For e

[answerhappygod]

We consider the following concepts related to the file system ofa hypothetical operating system (quasi-Linux):1. For each file, the operating system stores file managementinformation in an inode.2. An Inode is formed by a sequence of lines each consisting of 4bytes.3. A pointer consists of an address in the form of 4 bytes. Apointer in an Inode consists of a line of the Inode.4. An address references a sector of the secondary memory of size4096 bytes.5. An Inode contains at least one or more of the following pointersindicating file data locations:a. So-called simple pointers, each of which points to an address ofa sector in secondary memory.b. Double pointers, each of which points to an address where 1024single pointers that are outside the Inode can be searched.c. Triple pointers, each of which points to an address where 1024double pointers can be found outside the Inode.6. A symlink represents a kind of new name for an existing file.The creation of a symlink implies the creation of an informationlinking this symlink to the right Inode number corresponding to theconsidered file. This information, called hard-link, is stored in alocation that I agree to call the operating system directory. AnInode is created when the file is created and modified each time asymlink is created. The first name given to a file can beconsidered the first symlink of the file.
7. An Inode also contains:a. The number of symlinks that exist for a file, in a line of theInode.b. An identifier of the owner of the file in a line of theInode.c. A timestamp: indicating the date of creation of the file, in theform of 4 bytes forming a line of the Inode.8. A file is accessible in read or write mode.9. A file accessed in write mode by a process cannot be accessed byany other process simultaneously.10. Several processes can simultaneously access the same file inwrite mode.You are asked to model in UML the situation described above, alwaysusing the constructs of the UML notation.If necessary, or for readability reasons, your model may beprovided as several separate diagrams on several pages.A good model should:- Be as complete as possible in terms of fully describing the datain this assignment about the domain under consideration.- Be concise, in the sense of not trying to describe concepts thatare not required and that are outside the scope of the data in thisassignment. Thus, for example, you should avoid specifying throughyour model what a secondary memory is with concepts not mentionedin the statement of the assignment. Indeed, it is not required tospecify that a secondary memory is permanent, or that it is slowerthan a RAM, etc.- Be readable: not very cluttered by poor choices of constructs torepresent concepts (make the right choice of: attribute,association to a separate class, constraint, etc.).- Avoid redundancy.- If the model includes several diagrams, follow a logic thatjustifies why certain elements are found in one diagram and not inanother.