Models and Knowledge Representation Outline o What

Models and Knowledge Representation

Outline o What are models? n n The language of models Models and human comprehension o What are models used for? n n n Systems analysis models Systems inference models Systems design models o What roles do models play? n n Communication between stakeholders and the architect Design decisions and design assessment Guidelines for detail design Reusable Technical artifacts

Outline (Cont’d) o Modeling the problem and the solution domains n Problem domain models n Solution domain models o Views n Objectives and purpose models n Behavioral/functional models n Information/data models n Models of form n Nonfunctional/performance models o Summary

What Are Models? o A model of a software system is an abstract representation of knowledge about a system o It is an approximation or idealization of selected aspects of a system, such as: n n n Its structure Its behavior Its operation

What Are Models? (Cont’d) o Models are realized as: n n Diagrams, Formulae Textual descriptions Some combination of the above o Models may be grouped into views where each view represents some aspect of the system

Semantic Gap o It is the discontinuity between a thing being modeled and the model’s own representation of that thing. o It can also refer to the discontinuity between how the system works and the user’s perception of how it works. o The larger the semantic gap between a model and reality, the harder it is ot judge correctness of the model.

The Language of Models o Models are specified in modeling languages or notations and textual descriptions. o Natural language is needed where modeling notations don’t exist or are limited.

The Language of Models (Cont’d) o The three parts of interpreting system representation models n n n 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 o Models are meant to simplify tasks of reasoning about system properties. o Models allow us to focus on subsets of a problem. o Abstractions allow us to work in parallel and isolate developers form design decisions of other developers.

What Are Models Used For? o Models are used to: n Simulate existing systems – used to discover new behaviors of a system n Guide systems analysis and design – help people understand the characteristics of a system o A model can become: n A standard object model for a particular problem space n An implementation-independent model for guiding future versions of the system to take advantage of new technologies n An architecture or design pattern

What Are Models Used For? (Cont’d) o The four levels of systems knowledge – George Klir n n 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 o Systems analysis – trying to understand the system’s behavioral characteristics given its real or intended structure o Systems inference – trying to infer (discover) how a system works by observing its behavior o System design – trying to create a good design for a system that does not yet exist

Systems Analysis Models o In the context of software architecting, analysis applies to the (business) system we are trying to automate. o It is really problem space modeling.

Systems Inference Models o These are typically simulation models which are used to make predictions about an existing system’s future state or behavior. o The allow us to apply mathematical reasoning to a problem. o They enable us to understand, predict, and control the outcome in naturally occurring systems.

System Design Models o They are used for modeling a target system whose behavior we know, but whose form we don’t know. o Classic design principle: form follows function. o System design models are also known as solution domain models.

What Roles Do Models Play? o Models are a primary means of communication between all stakeholders. o Models provide guidelines for software developers to implement the system. o Models assist in making design decisions and assessing them. o Models can be reusable artifacts for future development and serve as documentation for system users and future maintainers.

Communication Between Stakeholders and the Architect o There are two goals of client communication: p Determine the client’s objectives and constraints p Ensure that the system reflects the client’s value judgments o The key to communication is using an agreed upon vocabulary. o Models assist by addressing specific concerns.

Design Decisions and Design Assessment o Models can be used to test assumptions. o It’s easier and cheaper to assess models as early as possible in the design phase. o Representation models allow us to reason about a system that does not yet exist. o Models capture design decisions throughout the design process.

Guidelines for Detail Design o The architecture assists in detail design by providing guidelines and models that help the developer make effective decisions. o 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 o Models that are part of an architectural description may be reused. o Software architects may design a new system based on prior systems.

Modeling the Problem and Solution Domains o Models can be divided into two groups: n Those that model the problem domain p Systems analysis models p Requirements analysis models n Those that model the solution domain p Technology independent models p Technology specific models

Problem Domain Models o The activity of creating problem domain models is called analysis. n n n Structured analysis Information modeling Object-oriented analysis o The goal is to minimize the semantic gap between the real system and its representation models.

Problem Domain Models (Cont’d) o Understanding the problem n Before requirements can be determined, it may be necessary to understand the characteristics of the system that is to be automated. o Analyzing the requirements n Requirements models are specifications of all known system functions and quality attributes including long term goals.

Solution Domain Models o The activity of creating solution domain models is called design. o It’s not always clear where analysis ends and design begins. o 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) o There are two categories of models: n Platform (technology)-independent (PIM) p These models generalize platform services without specifying a particular platform. n Platform (technology)-dependent p 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 o A view is a “representation of a whole system from the perspective of a related set of concerns. ” – IEEE o A view can contain one or more models. o Views are instances of viewpoints – a view is a technical specification and a viewpoint is the language of the view specification

Common Architectural Views o Objectives/purpose – describes what is needed. o Behavior/function – describes what the system does (to satisfy the objectives). o Information/data – describes the information (data and state) created by and retained in the system. o Form/structure – describes the physical structure of the software (e. g. , modules and components). o Performance – describes how effectively the system performs its functions.

Common Architectural Views (Cont’d) o The informational and behavioral views are the most common and are interdependent, but they are not sufficient. We also need n n n 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) o Views provide an integrated picture of the entire system. o Extraneous views and models can negatively impact the design process. o Missing views and models can increase the size of the semantic gap.

Objectives and Purpose Models o These models are sometimes called requirements analysis models. o They help the client to clarify abstract objectives and are written in the client’s and user’s language. o Some objectives can be expressed using use case models but these models are not sufficiently expressive to capture many nonfunctional requirements. o A requirements specification represents a family of solutions yielding many possible models.

Behavioral/Functional Models o These models specify what the system does. o It is important to achieve the right level of detail, not too much and not too little. o Since the software development is iterative, models must be refined at each iteration.

Behavioral Models o User interface prototypes – may be sample screens or functional prototypes o Scenarios and threads – typically done with use cases and sequence diagrams o 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. o Process models – data flow diagrams (DFDs) are used to identify system processes and their decomposition into subprocesses.

Information/Data Models o The data that is created and retained by an application and the relationships among that data are represented. o The data model may be the most complex part of a system. o Entity-relationship models (ERMs) were developed to model information complexity. o UML class diagrams are used for informational models even if the eventual implementation is in a relational database.

Models of Form o Models of form represent the structure of the system. o In complex systems it is not easy to infer the structure from its function and behavior. o Models include scale models (prototypes), components and connectors.

Models of Form: Scale Models o These include: n n n User interface prototypes Functionally limited models to test performance Performance-limited models to test proof of concepts o These models allow you to empirically test assumptions and compare design approaches.

Models of Form: Components and Connectors o These models are the software design models of most interest to software architects. o They include UML diagrams such as classes, object collaboration and component diagrams. o 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) o Types of activations: n n n 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) o Types of activations (Cont’d): n 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) n Hard pull – When the receiver requests the data, the sender is interrupted and must sent it. n 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 o These models describe or predict how effectively an architecture satisfies some function. o These models are usually quantitative and rely on human judgment to yield reliable performance indicators.

Summary o Creating models requires experience, insight, and creativity. o Understanding the types of models you can create helps frame your modeling activities. o Models can help save time and money and increase the odds of achieving the quality attributes by facilitating communication and problem understanding. o The challenge for the architect is how to decide which models to create and how detailed to make them.