Structural modeling captures the static features of a system through diagrams like class diagrams, object diagrams, deployment diagrams, package diagrams, and component diagrams. These structural models represent the framework and organization of a system's components and their relationships, but do not describe dynamic behavior. Common structural models include class diagrams, which show classes and associations between them, and UML component diagrams, which can be used to present architectural models of a system.
Structural modeling captures the static features of a system through diagrams like class diagrams, object diagrams, deployment diagrams, package diagrams, and component diagrams. These structural models represent the framework and organization of a system's components and their relationships, but do not describe dynamic behavior. Common structural models include class diagrams, which show classes and associations between them, and UML component diagrams, which can be used to present architectural models of a system.
Structural modeling captures the static features of a system through diagrams like class diagrams, object diagrams, deployment diagrams, package diagrams, and component diagrams. These structural models represent the framework and organization of a system's components and their relationships, but do not describe dynamic behavior. Common structural models include class diagrams, which show classes and associations between them, and UML component diagrams, which can be used to present architectural models of a system.
Structural modeling captures the static features of a system through diagrams like class diagrams, object diagrams, deployment diagrams, package diagrams, and component diagrams. These structural models represent the framework and organization of a system's components and their relationships, but do not describe dynamic behavior. Common structural models include class diagrams, which show classes and associations between them, and UML component diagrams, which can be used to present architectural models of a system.
Download as DOCX, PDF, TXT or read online from Scribd
Download as docx, pdf, or txt
You are on page 1of 4
Structural Modeling
Structural modeling captures the static features of a system. They consist
of the following − Classes diagrams Objects diagrams Deployment diagrams Package diagrams Composite structure diagram Component diagram Structural model represents the framework for the system and this framework is the place where all other components exist. Hence, the class diagram, component diagram and deployment diagrams are part of structural modeling. They all represent the elements and the mechanism to assemble them. The structural model never describes the dynamic behavior of the system. Class diagram is the most widely used structural diagram. Structural models of software display the organization of a system in terms of the components that make up that system and their relationships. Structural models may be static models, which show the structure of the system design, or dynamic models, which show the organization of the system when it is executing. You create structural models of a system when you are discussing and designing the system architecture. UML class diagrams are used when developing an object-oriented system model to show the classes in a system and the associations between these classes. An object class can be thought of as a general definition of one kind of system object. An association is a link between classes that indicates that there is some relationship between these classes. When you are developing models during the early stages of the software engineering process, objects represent something in the real world, such as a patient, a prescription, doctor, etc. Structural models of software display the organization of a system in terms of the components that make up that system and their relationships. Structural models may be static models, which show the structure of the system design or dynamic models, which show the organization of the system when it is executing. These are not the same things—the dynamic organization of a system as a set of interacting threads may be very different from a static model of the system components. You create structural models of a system when you are discussing and designing the system architecture. Architectural design is a particularly important topic in software engineering and UML component, package, and deployment diagrams may all be used when presenting architectural models. Deeper details on architectural modeling will be covered in the next chapter. Here we focus on the creation of the analysis-level class diagrams only that are useful for better understanding of the problem domain. Domains represent the different subject matters that we need to understand to build a system. A domain is an autonomous, real, hypothetical or abstract world inhabited by a set of conceptual entities that behave accordingto characteristic rules and policies. (Definition from [MELLOR2002].) We abstract like things and and call them classes. In forming such abstractions, we ignore most of the things as our aim is to leave out details and concentrate only on the important aspects. The remaining things are are grouped according to some perceptions about what is means to be "like". Data Dictionary A data dictionary is a file or a set of files that includes a database's metadata. The data dictionary hold records about other objects in the database, such as data ownership, data relationships to other objects, and other data. The data dictionary is an essential component of any relational database. Ironically, because of its importance, it is invisible to most database users. Typically, only database administrators interact with the data dictionary. The data dictionary, in general, includes information about the following: o Name of the data item o Aliases o Description/purpose o Related data items o Range of values o Data structure definition/Forms The name of the data item is self-explanatory. Aliases include other names by which this data item is called DEO for Data Entry Operator and DR for Deputy Registrar. Description/purpose is a textual description of what the data item is used for or why it exists. Related data items capture relationships between data items e.g., total_marks must always equal to internal_marks plus external_marks. Range of values records all possible values, e.g. total marks must be positive and between 0 to 100. Data structure Forms: Data flows capture the name of processes that generate or receive the data items. If the data item is primitive, then data structure form captures the physical structures of the data item. If the data is itself a data aggregate, then data structure form capture the composition of the data items in terms of other data items.