SE-UNIT-3 Part 1

Data modeling:
Data modeling is the process of creating a simplified diagram of a software system and the
data elements it contains, using text and symbols to represent the data and how it flows. Data
models provide a blueprint for designing a new database. Overall, data modeling helps an
organization use its data effectively to meet business needs for information.
A data model can be thought of as a flowchart that illustrates data entities, their attributes and
the relationships between entities. It enables data management and analytics teams to
document data requirements for applications and identify errors in development plans before
any code is written.
Data Models ensure consistency in naming conventions, default values, semantics, and
security while ensuring quality of the data. Data Model structure helps to define the relational
tables, primary and foreign keys and stored procedures. There are three types of Data Models
namely conceptual, logical, and physical.
 Entities represent real-world objects involved in a business. In an online store, customers,
the orders they place, and the items offered for sale are all entities. These are very similar
to a table in a database.
 Attributes are the characteristics that describe individual entities. For example, a
customer might be described by their first and last name, account number, and email
address.
 Relationships show which entities are connected.
 Example: - customers and orders would be connected because customers place orders.
 The conceptual data model represents the overall structure of data required to
support the business requirements independent of any software or data storage
structure.
 Logical data modeling functions to detail the attributes associated with a data
element. For example, a logical data model would specify the nature of a data
element, i.e., account name (string), account number (integer).
 A physical data model is a database-specific model that represents relational data
objects (for example, tables, columns, primary and foreign keys) and their
relationships.
Object Models:-
Object models describe the system in terms of object classes and their associations. An object
class is an abstraction over a set of objects with common attributes and the services (operations)
provided by each object.
Various object models may be produced

 Inheritance models
 Aggregation models
 Interaction models.
Natural ways of reflecting the real-world entities manipulated by the system more abstract
entities are more difficult to model using this approach
Object classes reflecting domain entities are reusable across systems
Inheritance models:
Organize the domain object classes into a hierarchy.
Classes at the top of the hierarchy reflect the common features of all classes.
Object classes inherit their attributes and services from one or more super-classes. These may be
specialized as necessary.
The UML is a standard representation devised by the developers of widely used object- oriented
analysis and design methods. It has become an effective standard for object-oriented modeling.
Notations Used:
Object classes are rectangles with the name at the top, attributes in the middle section and
operations in the bottom section;
Relationships between object classes (known as associations) are shown as lines linking objects;
Inheritance is referred to as generalization and is shown upwards rather than downwards in a
hierarchy.
Example: - Library Class Hierarchy:
Multiple inheritance:
Rather than inheriting the attributes and services from a single parent class, a system which
supports multiple inheritance allows object classes to inherit from several super-classes.
This can lead to semantic conflicts where attributes/services with the same name in different
super classes have different semantics.
Multiple inheritance makes class hierarchy reorganization more complex.
Multiple inheritance examples:
Object aggregation:
An aggregation model shows how classes that are collections are composed of other classes.
Aggregation models are similar to the part-of relationship in semantic data models.
Object aggregation Example:

STRUCTURED METHODS:
This is a systematic and structured method of checking the documented output from any stage of
the system development process in order to identify omissions and errors.
Structured methods incorporate system modeling as an inherent part of the method.

Methods define a set of models, a process for deriving these models and rules and guidelines that
should apply to the models.
CASE tools support system modeling as part of a structured method.
METHOD WEAKNESSES:
They do not model non-functional system requirements.

They do not usually include information about whether a method is appropriate for a given
problem.
They may produce too much documentation.
The system models are sometimes too detailed and difficult for users to understand.
CASE WORKBENCHES:
It is a coherent set of tools that are designed to support related software process activities such as
analysis, design and testing.
Analysis and design workbenches support system modeling during both requirements
Engineering and system design.
These workbenches may support a specific design method or may provide support for a creating
several different types of system model.
AN ANALYSIS AND DESIGN WORKBENCH:

ANALYSIS WORKBENCH COMPONENTS:
Diagram editors
Model analysis and checking tools Repository and associated query language Data dictionary
Report definition and generation tools Forms definition tools
Import/export translators
Code generation tools

SE-UNIT-3 Part 1

Uploaded by

Copyright:

Available Formats

SE-UNIT-3 Part 1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SE-UNIT-3 Part 1

Uploaded by

Copyright:

Available Formats

Data modeling:

Various object models may be produced

Example: - Library Class Hierarchy:

Object aggregation Example:

Structured methods incorporate system modeling as an inherent part of the method.

They do not model non-functional system requirements.

AN ANALYSIS AND DESIGN WORKBENCH:

You might also like