1. Models and Knowledge Representation

2. 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

3. 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

4. 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

5. 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

6. 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.

7. 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.

8. 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

9. 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.

10. 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

11. 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

12. 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

13. 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.

14. 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.

15. 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.

16. 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.

17. 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.

18. 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.

19. 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.

20. 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.

21. 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

22. 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.

23. 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.

24. 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.

25. 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.

26. 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

27. 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.

28. 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

29. 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.

30. 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.

31. 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.

32. 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.

33. 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.

34. 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.

35. 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.

36. 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.

37. 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)

38. 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.

39. 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.

40. 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.