Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Lecture 1.2.4

Download as docx, pdf, or txt
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.

You might also like