Chapter 9: Software Engineering Models
- 3GL
- 3rd Generation Language
- BNF
- Backus-Naur Form
- FDD
- Feature-Driven Development
- IDE
- Integrated Development Environment
- PBI
- Product Backlog Item
- RAD
- Rapid Application Development
- UML
- Unified Modeling Language
- XP
- eXtreme Programming
Software engineering models and methods impose structure on software engineering with the goal of making that activity systematic, repeatable, and ultimately more success-oriented. Using models provides an approach to problem solving, a notation, and procedures for model construction and analysis. Methods provide an approach to the systematic specification, design, construction, test, and verification of the end-item software and associated work products. Software engineering models and methods vary widely in scope—from addressing a single software life cycle phase to covering the complete software life cycle. The emphasis in this knowledge area (KA) is on software engineering models and methods that encompass multiple software life cycle phases, since methods specific for single life cycle phases are covered by other KAs.
This chapter on software engineering models and methods is divided into four main topic areas:
- Modeling: discusses the general practice of modeling and presents topics in modeling principles; properties and expression of
models; modeling syntax, semantics, and pragmatics; and preconditions, postconditions, and invariants.
- Types of Models: briefly discusses models and aggregation of submodels and provides some general characteristics of model types
commonly found in the software engineering practice.
- Analysis of Models: presents some of the common analysis techniques used in modeling to verify completeness, consistency, correctness, traceability, and interaction.
- Software Engineering Methods: presents a brief summary of commonly used software engineering methods. The discussion guides the reader through a summary of heuristic methods, formal methods, prototyping, and agile methods.
The breakdown of topics for the Software Engineering Models and Methods KA is shown in Figure 9.1.
1 Modeling
Modeling of software is becoming a pervasive technique to help software engineers understand, engineer, and communicate aspects of the software to appropriate stakeholders. Stakeholders are those persons or parties who have a stated or implied interest in the software (for example, user, buyer, supplier, architect, certifying authority, evaluator, developer, software engineer, and perhaps others). While there are many modeling languages, notations, techniques, and tools in the literature and in practice, there are unifying general concepts that apply in some form to them all. The following sections provide background on these general concepts.
1.1 Modeling Principles
Modeling provides the software engineer with an organized and systematic approach for representing significant aspects of the software under study, facilitating decision-making about the software or elements of it, and communicating those significant decisions to others in the stakeholder communities. There are three general principles guiding such modeling activities:
- Model the Essentials: good models do not usually represent every aspect or feature of the software under every possible condition.
Modeling typically involves developing only those aspects or features of the software that need specific answers, abstracting away any nonessential information. This approach keeps the models manageable and useful.
- Provide Perspective: modeling provides views of the software under study using a defined set of rules for expression of the
model within each view. This perspective driven approach provides dimensionality to the model (for example, a structural view, behavioral view, temporal view, organizational view, and other views as relevant). Organizing information into views focuses the software modeling efforts on specific concerns relevant to that view using the appropriate notation, vocabulary, methods, and tools.
- Enable Effective Communications: modeling employs the application domain vocabulary of the software, a modeling language, and
semantic expression (in other words, meaning within context). When used rigorously and systematically, this modeling results in a reporting approach that facilitates effective communication of software information to project stakeholders.
A model is an abstraction or simplification of a software component. A consequence of using abstraction is that no single abstraction completely describes a software component. Rather, the model of the software is represented as an aggregation of abstractions, which — when taken together — describe only selected aspects, perspectives, or views — only those that are needed to make informed decisions and respond to the reasons for creating the model in the first place. This simplification leads to a set of assumptions about the context within which the model is placed that should also be captured in the model. Then, when reusing the model, these assumptions can be validated first to establish the relevancy of the reused model within its new use and context.
1.2 Properties and Expression of Models
Properties of models are those distinguishing features of a particular model used to characterize its completeness, consistency, and correctness within the chosen modeling notation and tooling used. Properties of models include the following:
- Completeness: the degree to which all requirements have been implemented and verified within the model.
- Consistency: the degree to which the model contains no conflicting requirements, assertions, constraints, functions, or component
descriptions.
- Correctness: the degree to which the model satisfies its requirements and design specifications and is free of defects.
Models are constructed to represent real-world objects and their behaviors to answer specific questions about how the software is expected to operate. Interrogating the models — either through exploration, simulation, or review—may expose areas of uncertainty within the model and the software to which the model refers. These uncertainties or unanswered questions regarding the requirements, design, and/or implementation can then be handled appropriately. The primary expression element of a model is an entity. An entity may represent concrete artifacts (for example, processors, sensors, or robots) or abstract artifacts (for example, software modules or communication protocols). Model entities are connected to other entities using relations (in other words, lines or textual operators on target entities). Expression of model entities may be accomplished using textual or graphical modeling languages; both modeling language types connect model entities through specific language constructs. The meaning of an entity may be represented by its shape, textual attributes, or both. Generally, textual information adheres to language-specific syntactic structure. The precise meanings related to the modeling of context, structure, or behavior using these entities and relations is dependent on the modeling language used, the design rigor applied to the modeling effort, the specific view being constructed, and the entity to which the specific notation element may be attached. Multiple views of the model may be required to capture the needed semantics of the software. When using models supported with automation, models may be checked for completeness and consistency. The usefulness of these checks depends greatly on the level of semantic and syntactic rigor applied to the modeling effort in addition to explicit tool support. Correctness is typically checked through simulation and/or review.
