Download
1 / 40
400 likes | 414 Views
Learn about the importance of models in software systems design, their language, roles, and communication between stakeholders and architects.
E N D
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: • Softpush – The sender sends a message which may be lost if the receiver is off-line or not explicitly waiting to receive the message. • Hardpush – The sender sends a message and the act of sending interrupts the receiver who must react to the message. • Blockingpull – 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-blockingpull – 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) • Hardpull – When the receiver requests the data, the sender is interrupted and must sent it. • Queuingchannel – 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.
