Models and Knowledge Representation

Outline

What are models? The language of models Models and human comprehension

What are models used for? Systems analysis models Systems inference models Systems design models

What roles do models play? Communication between stakeholders and the architect Design decisions and design assessment Guidelines for detail design Reusable Technical artifacts

Outline (Cont’d)

Modeling the problem and the solution domains Problem domain models Solution domain models

Views Objectives and purpose models Behavioral/functional models Information/data models Models of form Nonfunctional/performance models

Summary

What Are Models?

A model of a software system is an abstract representation of knowledge about a system

It is an approximation or idealization of selected aspects of a system, such as: Its structure Its behavior Its operation

What Are Models? (Cont’d)

Models are realized as: Diagrams, Formulae Textual descriptions Some combination of the above

Models may be grouped into views where each view represents some aspect of the system

Semantic Gap

It is the discontinuity between a thing being modeled and the model’s own representation of that thing.

It can also refer to the discontinuity between how the system works and the user’s perception of how it works.

The larger the semantic gap between a model and reality, the harder it is ot judge correctness of the model.

The Language of Models

Models are specified in modeling languages or notations and textual descriptions.

Natural language is needed where modeling notations don’t exist or are limited.

The Language of Models (Cont’d) The three parts of interpreting system

representation models Syntax – how to use elements and in what

ways can they be organized, connected, or related

Semantics – the meaning of a particular model

Pragmatics – the broader context in which a model is related and the constraints and assumptions affecting the model

Models and Human Comprehension

Models are meant to simplify tasks of reasoning about system properties.

Models allow us to focus on subsets of a problem.

Abstractions allow us to work in parallel and isolate developers form design decisions of other developers.

What Are Models Used For?

Models are used to: Simulate existing systems – used to discover new

behaviors of a system Guide systems analysis and design – help people

understand the characteristics of a system A model can become:

A standard object model for a particular problem space

An implementation-independent model for guiding future versions of the system to take advantage of new technologies

An architecture or design pattern

What Are Models Used For? (Cont’d) The four levels of systems knowledge – George

Klir Source: The variables we know about and wish to

measure or observe in order to gather data about the system.

Data: The data that we have collected form the source system.

Generative: A model or means for generating the data of the previous level.

Structure: an assemblage of components that implement the generative model

The Three Fundamental Systems Problems

Systems analysis – trying to understand the system’s behavioral characteristics given its real or intended structure

Systems inference – trying to infer (discover) how a system works by observing its behavior

System design – trying to create a good design for a system that does not yet exist

Systems Analysis Models

In the context of software architecting, analysis applies to the (business) system we are trying to automate.

It is really problem space modeling.

Systems Inference Models

These are typically simulation models which are used to make predictions about an existing system’s future state or behavior.

The allow us to apply mathematical reasoning to a problem.

They enable us to understand, predict, and control the outcome in naturally occurring systems.

System Design Models

They are used for modeling a target system whose behavior we know, but whose form we don’t know.

Classic design principle: form follows function.

System design models are also known as solution domain models.

What Roles Do Models Play?

Models are a primary means of communication between all stakeholders.

Models provide guidelines for software developers to implement the system.

Models assist in making design decisions and assessing them.

Models can be reusable artifacts for future development and serve as documentation for system users and future maintainers.

Communication Between Stakeholders and the Architect There are two goals of client

communication: Determine the client’s objectives and

constraints Ensure that the system reflects the client’s

value judgments

The key to communication is using an agreed upon vocabulary.

Models assist by addressing specific concerns.

Design Decisions and Design Assessment

Models can be used to test assumptions. It’s easier and cheaper to assess models

as early as possible in the design phase. Representation models allow us to

reason about a system that does not yet exist.

Models capture design decisions throughout the design process.

Guidelines for Detail Design

The architecture assists in detail design by providing guidelines and models that help the developer make effective decisions.

Architectural models such as design structure matrix (DSM) and the task structure matrix (TSM) assist in work breakdown by indicating what can be developed in parallel.

Reusable Technical Artifacts

Models that are part of an architectural description may be reused.

Software architects may design a new system based on prior systems.

Modeling the Problem and Solution Domains

Models can be divided into two groups: Those that model the problem domain

Systems analysis models Requirements analysis models

Those that model the solution domain Technology independent models Technology specific models

Problem Domain Models

The activity of creating problem domain models is called analysis. Structured analysis Information modeling Object-oriented analysis

The goal is to minimize the semantic gap between the real system and its representation models.

Problem Domain Models (Cont’d)

Understanding the problem Before requirements can be determined, it

may be necessary to understand the characteristics of the system that is to be automated.

Analyzing the requirements Requirements models are specifications of

all known system functions and quality attributes including long term goals.

Solution Domain Models

The activity of creating solution domain models is called design.

It’s not always clear where analysis ends and design begins.

One of the main purposes of solution domain design is to serve as a basis for the division of labor for system construction.

Solution Domain Models (Cont’d)

There are two categories of models: Platform (technology)-independent (PIM)

These models generalize platform services without specifying a particular platform.

Platform (technology)-dependent These models map a PIM to a specific

technology and the generalized system structures to programming language constructs. These models serve as development guidelines.

Views

A view is a “representation of a whole system from the perspective of a related set of concerns.” – IEEE

A view can contain one or more models. Views are instances of viewpoints – a

view is a technical specification and a viewpoint is the language of the view specification

Common Architectural Views

Objectives/purpose – describes what is needed. Behavior/function – describes what the system

does (to satisfy the objectives). Information/data – describes the information

(data and state) created by and retained in the system.

Form/structure – describes the physical structure of the software (e.g., modules and components).

Performance – describes how effectively the system performs its functions.

Common Architectural Views (Cont’d)

The informational and behavioral views are the most common and are interdependent, but they are not sufficient. We also need Views of distribution Views of user and external systems

interaction Views that specify how commercial or

standard technologies are used

Common Architectural Views (Cont’d)

Views provide an integrated picture of the entire system.

Extraneous views and models can negatively impact the design process.

Missing views and models can increase the size of the semantic gap.

Objectives and Purpose Models These models are sometimes called

requirements analysis models. They help the client to clarify abstract objectives

and are written in the client’s and user’s language.

Some objectives can be expressed using use case models but these models are not sufficiently expressive to capture many nonfunctional requirements.

A requirements specification represents a family of solutions yielding many possible models.

Behavioral/Functional Models

These models specify what the system does.

It is important to achieve the right level of detail, not too much and not too little.

Since the software development is iterative, models must be refined at each iteration.

Behavioral Models

User interface prototypes – may be sample screens or functional prototypes

Scenarios and threads – typically done with use cases and sequence diagrams

State transition diagrams – finite state machines that represent the behavior of a system as a set of states, transitions between states, and events that trigger transitions.

Process models – data flow diagrams (DFDs) are used to identify system processes and their decomposition into subprocesses.

Information/Data Models

The data that is created and retained by an application and the relationships among that data are represented.

The data model may be the most complex part of a system.

Entity-relationship models (ERMs) were developed to model information complexity.

UML class diagrams are used for informational models even if the eventual implementation is in a relational database.

Models of Form

Models of form represent the structure of the system.

In complex systems it is not easy to infer the structure from its function and behavior.

Models include scale models (prototypes), components and connectors.

Models of Form: Scale Models

These include: User interface prototypes Functionally limited models to test

performance Performance-limited models to test proof of

concepts These models allow you to empirically

test assumptions and compare design approaches.

Models of Form: Components and Connectors These models are the software design

models of most interest to software architects.

They include UML diagrams such as classes, object collaboration and component diagrams.

Models of activation represent how information flows through the components of a system, as well as how control is passed from component to component.

Models of Form: Components and Connectors (Cont’d)

Types of activations: Soft push – The sender sends a message

which may be lost if the receiver is off-line or not explicitly waiting to receive the message.

Hard push – The sender sends a message and the act of sending interrupts the receiver who must react to the message.

Blocking pull – The receiver requests the data and waits until the sender responds (also known as synchronous in UML)

Models of Form: Components and Connectors (Cont’d) Types of activations (Cont’d):

Non-blocking pull – The receiver requests the data and continues on without it if the sender does not sent it. This includes blocking for a period of time (also known as balking or timeout in UML)

Hard pull – When the receiver requests the data, the sender is interrupted and must sent it.

Queuing channel – The sender pushes data onto a channel without interrupting the receiver. The data can be stored in the channel so that the receiver can pull it later.

Nonfunctional/Performance Models

These models describe or predict how effectively an architecture satisfies some function.

These models are usually quantitative and rely on human judgment to yield reliable performance indicators.

Summary

Creating models requires experience, insight, and creativity.

Understanding the types of models you can create helps frame your modeling activities.

Models can help save time and money and increase the odds of achieving the quality attributes by facilitating communication and problem understanding.

The challenge for the architect is how to decide which models to create and how detailed to make them.