Module -4

a) System Models: Context models; Behavioral models; Data models; Object models; Structured methods

b) Architectural Design: Architectural design decisions; System organization; Modular decomposition styles;
Control styles, reference architectures .

c) Application architectures: Data-processing systems, Transaction-processing systems, Event processing

systems, Language-processing system .
a) System models
• System modelling is the process of developing abstract models of a
system.
⚫ System models express system requirements in a more technical
way.
⚫ System specifications are documented using a set of system models.
⚫ Important bridge between the analysis and design processes.
• System modelling helps the analyst to understand the system. ⚫
Models are used to communicate with customers
Different models present the system from different perspectives:
• External perspective - showing the system’s context / environment;
• Interaction perspective - showing the interactions between a system
and its environment or between the components of a system.
• Behavioral perspective - showing the behaviour of the system;
• Structural perspective - showing the system architecture or data
architecture.
❖Models of the existing system - used to
• • Clarify what the existing system does
• • Basis for discussing its strengths and weaknesses
• • Lead to requirements for the new system
❖Models of the new system - used to
• Explain the proposed requirements to other system stakeholders
• Discuss design proposals
• Document the system for implementation.
• In a model-driven engineering process – used to
• • Generate a complete or partial system implementation from the
system model.
∙ A model is an abstract view of a system that ignores some system details.
∙ Models are used in the analysis process to understand the existing system or specify the new system.
Different models represent the system from various perspectives.
Context models
• Context models show how the system being modelled is positioned in an
environment with other systems and processes. They define the boundaries of the
system.

⮚ Once system boundaries are determined, a key part of analysis is defining the
system's context and its environmental dependencies. Typically, creating a simple
architectural model is the initial step in this process, helping to clarify these
relationships.
Example : An ATM (bank auto-teller System) is as shown in figure below
⮚ Figure 8.1 presents an architectural model of a bank auto-teller network
information system (ATM). High-level models like this use block diagrams with
named rectangles for subsystems and lines indicating associations.
⮚ In the model, each ATM is connected to an account database, a local branch
accounting system, a security system, and a maintenance support system.
⮚ It also links to a usage database for network monitoring and a local branch
counter system, which offers backup and printing services.
Process model for equipment procurement in an organization.

• This process includes specifying required equipment,

selecting suppliers, ordering, receiving, and testing the
equipment.
• When designing computer support for this process, decisions
must be made about which activities will be supported, as
others fall outside the system boundary.
• In the model, a dotted line indicates which activities are
within the system’s boundary.
Behavioural models

∙ Behavioural models are used to describe the overall behaviour of the system.
∙ Two types are commonly discussed:
1. data-flow models, which represent data processing within the system(data driven)
2. state machine models, which depict the system's responses to events.(event driven)
∙ Depending on the system's nature, these models can be used individually or in
combination.
1 . Data-flow models
• Data-flow models are an easy way of showing how data is processed
by a system.
• Data-flow models are used to show how data flows through a
sequence of processing steps.
• Figure below illustrates a data-flow model for processing an order for
goods, such as computer equipment, within an organization.
• This model specifically details of data processing within the "Place
equipment order" activity from the broader process model in Figure
8.2.
• It traces the flow of the order through various processes and indicates
data stores involved, such as the Orders file and Budget file.
Data-flow diagram of order processing
• Data-flow models provide a functional perspective, with each
transformation representing a single function or process.
• They are especially helpful in requirements analysis, as they display
end-to-end processing within a system—from input to the resulting
output or system response.
• Figure 8.4 demonstrates this application with a data-flow diagram of
the processing within an insulin pump
2. State machine models:

∙ A state machine model describes how a system responds to internal or external

events.
∙ The state machine model shows system states and events that cause transitions
from one state to another. It does not show the flow of data within the system.
∙ This type of model is often used for modelling real-time systems because these
systems are often driven by stimuli from the system’s environment.
∙ For example, the real-time alarm system that responds to stimuli from movement
sensors, door opening sensors, and so on.
∙ Figure below shows a state machine model of a simple microwave
oven equipped with buttons to set the power and the timer to start the
system.
∙ The rounded rectangles in a model represent system states. They
include a brief description (following ‘do’) of the actions taken in that
state. The labelled arrows represent stimuli that force a transition
from one state to another.
• Real microwave ovens are actually much more complex than the
system described here. The sequence of actions are:

• 1. Select the power level (either half-power or full-power).

• 2. Input the cooking time.

• 3. Press Start, and the food is cooked for the given time.
∙ The system responds initially to either the full-power or the half-power button.
Users can change their mind after selecting one of these and press the other
button. The time is set and, if the door is closed, the Start button is enabled.
Pushing this button starts the oven operation and cooking takes place for the
specified time.

• For safety reasons, the oven should not operate when the door is open and, on
completion of cooking, a buzzer is sounded. The oven has a very simple
alphanumeric display that is used to display various alerts and warning messages.
Data models:

• Semantic data models define the logical structure of the data processed by a
software system.
• They represent the organization, relationships, and constraints of data elements,
focusing on the real-world meaning of the data to ensure it aligns with the
system’s requirements.
• This modeling is essential for efficient data handling and helps ensure that the
database structure supports the system’s functionality and interactions.
• The most widely used data modelling technique is Entity-Relation-Attribute
modelling (ERA modelling), which shows the data entities, their associated
attributes and the relations between these entities. As shown in fig below.
• LIBSYS is designed to deliver copies of copyrighted articles that have
been published in magazines and journals and to collect payments for
these articles.
• Therefore, the data model must include information about the article,
the copyright holder and the buyer of the article.
1. Graphical Models Lack Detail: Graphical models like data models provide an overview but do
not capture all the details about entities, relationships, and attributes. Therfore
o Detailed descriptions should accompany graphical models.

o These descriptions can be stored in a repository or data dictionary.

2. USE of Data Dictionaries:

o Data dictionaries are helpful for managing information across different types of system
models.
o They serve as a centralized resource for understanding the components of a model.
Structure of a Data Dictionary:
o Alphabetic Listing: A structured, alphabetized list of all names in the system models.

o Details Included:

▪ Name of the entity or object.

▪ Description of the entity or object.

▪ If composite, a breakdown of its components.

o Additional metadata (optional):

▪ Date of creation.

▪ Creator's identity.

▪ Representation of the entity.

• All system names, including entities, relations, attributes, and
services, should be recorded in the data dictionary, often using
software for creation, maintenance, and querying.
• This software is typically integrated with tools like CASE systems,
which can automate dictionary updates by adding names as they appear
in the model.
Object models
• The object-oriented approach is widely used in software development, especially
for interactive systems, involving object models for requirements, design, and
implementation in languages like Java or C++.
• Object models developed during requirements analysis represent both system data
and processing, combining the roles of data-flow and semantic data models.
• They are effective in showing how entities are classified and composed of other
entities.
• This approach works naturally for systems dealing with tangible entities, such as
cars or books, due to their clear attributes.
• However, abstract entities like a library or a medical record system are harder to
model as object classes because their interfaces may not consist of straightforward
attributes and operations.
• Various object-oriented analysis methods emerged in the 1990s, but
key contributors Booch, Rumbaugh, and Jacobsen unified their
approaches into the Unified Modeling Language (UML), now a
standard for object modeling.
• UML provides notations for various system models, including use-case
models, sequence diagrams, and state machine models.
• In UML, an object class is depicted as a vertically oriented rectangle
divided into three sections:
1. the class name at the top,
2. Attributes in the middle,
3. Operations at the bottom.
• Object models describe the logical system entities and their
classification and aggregation. They combine a data model with a
processing model.
Possible object models that may be developed include
• Inheritance models,
• Aggregation models and
• Behavioural models.
a) Inheritance models

• Object-oriented modeling identifies key object classes in a domain

and organizes them into a taxonomy, a classification scheme showing
relationships through common attributes and services.
• This taxonomy is displayed as an inheritance hierarchy, with general
object classes at the top and specialized classes inheriting and
extending attributes and services.
• Specialized classes may also define their own unique attributes and
services.
• Figure 8.10 illustrates a simplified class hierarchy for a library model,
showing the general class "Library Item" at the top with common
attributes and services inherited by subclasses like "Published Item"
and "Recorded Item." These subclasses add specific attributes, further
inherited by more specialized lower-level items like books or films.
• Figure 8.11 depicts another inheritance hierarchy for library users,
distinguishing between those who can borrow books and those
restricted to in-library reading. In UML, inheritance is represented as a
"generalization relationship," with arrows pointing upwards from
subclasses to superclasses, differing from other notations or
languages like Java. This structure visually emphasizes the flow of
shared attributes and operations from general to specific classes.
• Figures 8.10 and 8.11 depict single inheritance hierarchies where each class inherits
attributes and operations from a single parent,
• while Figure 8.12 introduces a multiple inheritance model where a class can inherit
from several parents.
• In multiple inheritance, the class's attributes and operations are a combination of those
from all its superclasses.
• Challenges with multiple inheritance include designing an inheritance graph that avoids
unnecessary attributes, reorganizing the graph when changes are needed, and resolving
name clashes between attributes from different superclasses.
• These issues are manageable during system modeling by manually adjusting the object
model but can become more problematic in object-oriented programming. Despite its
complexity, multiple inheritance can be useful for modeling scenarios where
overlapping behaviors or properties need to be represented.
b) Object aggregation
• Objects can also form groupings through aggregation, where an object serves
as a composite of other objects.
• This relationship is represented in UML using an aggregation model, such as
the example in Figure 8.13, which depicts a "Study Pack" as a composite library
item.
• The study pack includes various components like lecture notes, exercises,
sample solutions, OHP slide packages, and videotapes. In UML, aggregation is
visually denoted by a diamond shape at the source of the link, indicating the
composite relationship.
• For instance, Figure 8.13 can be interpreted as "A study pack is composed of
one or more assignments, OHP slide packages, lecture notes, and videotapes."
c) Object behaviour modelling
• To model object behavior, UML uses scenarios represented as use cases and
sequence diagrams to show action sequences.
• In the sequence diagram for the LIBSYS system, objects and actors are
arranged along the top, with arrows representing the sequence of
operations.
• The user first accesses the catalogue to check for electronic availability of
an item, and if available, requests its electronic issue.
• The system then initiates a transaction where the license for the item is
agreed upon, ensuring copyright compliance.
• After licensing, the item is sent to a network server for compression before
being delivered to the user.
❖ Structured methods

• Structured methods are systematic approaches developed in the 1970s to support

software analysis and design.
• They provide a framework for detailed system modeling during requirements
elicitation and analysis.
• Each structured method typically has its own set of preferred system models,
processes, rules, and guidelines for model creation.
• Standard documentation is produced as part of these methods, and CASE tools
often assist with model editing, code generation, report generation, and model-
checking.
• These methods have been successful in large projects, delivering cost reductions
through standard notations and documentation practices.
Structured methods have several weaknesses, including:

• They do not provide effective support for understanding or modelling

nonfunctional system requirements.
• A lack of guidelines to help users determine the appropriateness of the method for
specific problems or environments.
• The production of excessive documentation, which can hide the core system
requirements.
• The models that are produced are very detailed, and users often find them difficult
to understand. These users therefore cannot check the realism of these models.
• Analysis and design CASE tools support the creation, editing
and analysis of the graphical notations used in structured
methods.
• Figure 8.15 shows the components that may be included
method support environment.
1. A data dictionary that maintains
information about the entities used in a
system design.
2. Structured Diagram Tools used to
create object models, data models,
behavioural models, and so on. These
editors are not just drawing tools but
are aware of the types of entities in the
diagram. They capture information
about these entities and save this
information in the central repository.
3. Report definition and
generation tools that take
information from the central store
and automatically generate system
documentation.
4. Repository query languages that
allow the designer to find designs
and associated design information
in the repository.
5. Import/export facilities that allow
the interchange of information from
the central repository with other
development tools.

6. Design analysis and checking tools

that process the design and report on
errors and anomalies. These may be
integrated with the editing system so
that user errors are trapped at an early
stage in the process.
7. Forms creation tools that allow
screen and document formats to be
specified.

8. Code generators that generate

code or code skeletons
automatically from the design
captured in the central store.
THANK YOU