Software Engineering Models and Methods

Software engineering models and methods provide structure and systematization to the software engineering process, enabling repeatability and increased success for computer science and software development projects. Models offer an approach to problem solving using notation and procedures for constructing and analyzing representations. Methods supply a systematic means of specifying, designing, building, testing, and verifying the end software product and associated work items. Models and methods range from addressing a single phase to the full software development life cycle (SDLC). This knowledge area examines multi-phase methods, complementing other areas on single-phase techniques.

Topics here encompass modeling principles; model properties and expression; modeling syntax semantics and pragmatics; preconditions, postconditions and invariants; and model types like structural and behavioral models. It also includes model analysis for completeness, consistency, correctness, traceability and interaction, and software engineering methods including heuristic, formal, prototyping, and Agile.

Heuristic methods rely on experience, applying techniques like structured analysis and design, data modeling, object-oriented analysis and design, aspect-oriented development, and model-driven/based development. Formal methods use mathematical rigor to specify, develop, and verify software. Prototyping rapidly produces incomplete versions of an application to elicit feedback. Agile methods like extreme programming (XP) incorporate short, iterative cycles, adaptive planning, and continuous improvement to reduce overhead for smaller projects.

Read more about software engineering models and methods in the Software Engineer Book of Knowledge (SWEBOK)

Software modeling involves creating abstract representations of the most significant aspects of the software under study. It provides a means for software engineers, the development team and other stakeholders to analyze, reason about, and understand key elements of the structure, behavior, intended use, and assembly considerations of the software. Modeling facilitates making important decisions about the software or components. It also enables effective communication of software information to various stakeholders.

Models are abstractions and, as such, do not usually encompass every feature or nuance of the software under every possible condition. Modeling typically focuses on capturing aspects or characteristics of the software that are most relevant to addressing specific issues or questions. By omitting inessential details, modeling keeps the representations understandable and manageable in size and complexity. This abstraction enables modelers to focus on the most critical parts of the software needed to make informed decisions and responding to core modeling reasons.

Back to Top

There are three overarching principles that guide software modeling activities:

1. Model the essentials: Good models do not represent every minor feature for all scenarios. Modeling involves the most salient aspects needed to address the specific issues or questions. Trivial details are abstracted away to keep the model understandable and wieldy. This focuses on key characteristics for informed decision-making.
2. Provide perspective: Modeling constructs different views using defined rules to express each within the chosen modeling language and tools. This multifaceted, perspective-driven approach brings dimensionality. For example, models may provide structural, behavioral, temporal or organizational views. Organizing into separate views focuses on modeling for each view on specific concerns.
3. Enable effective communication: Diligent, uniform modeling facilitates straightforwardly conveying software information to stakeholders. Careful use of domain terminology and modeling language semantics enables articulation in a familiar vocabulary. Strict syntactic and semantic adherence also improves expression. Explicit notation contributes to communicative models, while modeling pragmatics helps share unambiguous meaning.

Back to Top

Some of the essential distinguishing properties that characterize software models and express their relative quality are completeness, consistency, and correctness. These terms are defined and described as follows:

Completeness: This property conveys the degree to which all specified requirements, features, and elements have been fully implemented and sufficiently verified or validated within the model representation of the software. A complete model incorporates all the relevant requirements exhaustively.

Consistency: This characteristic demonstrates the degree to which the software model contains no contradictory, conflicting, or mutually exclusive requirements, assertions, constraints, functions, behaviors, or component descriptions. A consistent model is one in which all parts are cohesive and compatible.

Correctness: This attribute expresses the degree to which the software model accurately satisfies and implements all specified software requirements and design specifications. A correct model is free of any defects and misrepresentations, and ultimately meets the needs of its stakeholders as intended.

Models are constructed to represent real-world objects, events, behaviors, and interactions to answer specific questions about how the software is expected to operate or perform under certain conditions. By providing abstractions of reality, models give software engineers a way to study, explore, and test the software’s structure and behavior. The goal is to use models to reveal areas of uncertainty, vagueness, or incompleteness within the understanding of the software. Uncovering these gaps in comprehension through interrogating the models then provides intelligent direction for software engineers to address the issues appropriately.

The primary units of expression in a software model are entities. An entity may represent a concrete artifact or element in the physical world, such as processors, sensors, controls, displays, robotic mechanisms, etc. Alternatively, it may depict an abstract artifact or conceptual element such as software components, modules, communication protocols, etc. Software model entities are connected to other entities using relations. The most common way to represent relations is with connecting lines or arrows drawn between model elements. Both textual and graphical modeling languages define specific constructs to express and manage these connections between entities.

A model entity’s visual shape or form can communicate part of its meaning within the model. Textual attributes attached to the entity usually also carry much of the semantic meaning. Generally, any textual information shown in a model adheres to the syntactic structure defined by the rules of the particular modeling language employed.

The precise meanings of the modeling constructs used to represent the contextual environment, the structural architecture, and the dynamic behaviors and interactions of a software component are largely dependent on four factors:

1) The specific modeling language used.

2) The way in which that modeling language allows its entities, relations, and other constructs to be visually rendered and textually annotated.

3) The particular perspective or view being constructed with the model.

4) The types of entities to which the notation can be applied.

Back to Top

A typical software model consists of an aggregation of multiple submodels. Each submodel provides a partial, simplified description and representation of some aspect or perspective of the software under consideration. Submodels are created for very specific, well-defined purposes. An individual submodel may comprise one or more diagrams, textual descriptions, and other modeling constructs.

The collection of submodels may use multiple different modeling languages, both graphical and textual, or they may employ a single common modeling language. The particular aggregation of submodels is determined by the specific reasons and goals that drove the need for modeling in the first place. The submodels work together to fully address those motivations.

Back to Top

The Unified Modeling Language (UML) is a broadly adopted graphical modeling language in the field of software engineering. It defines a rich collection of diagram types that software engineers can use to develop structural and behavioral models representing different perspectives of a software system.

Some examples of UML diagram types used for structural modeling include class diagrams, component diagrams, object diagrams, deployment diagrams and package diagrams. Behavioral modeling diagrams defined in UML include state machine diagrams, activity diagrams, communication diagrams and sequence diagrams.

These UML diagrams provide visual constructs to model the software from the chosen perspective. However, it is the rules, syntax, semantics, and notation defined by the UML modeling language that give meaning and precision to the elements placed on these diagrams. The diagrams themselves are merely visual canvases to capture and convey models using the UML language.

Back to Top

Behavioral modeling is a model type that focuses on identifying and defining the dynamic behavioral aspects of software components. The goal is to represent how software functions, features, and system elements behave when in operation.

Behavioral models generally take one of three basic forms:

1. State machine representations – These models depict software behavior in terms of defined states that the software or components can be in, along with events that can trigger transitions between those states. State machine modeling is valuable for elucidating complex workflows, protocols, lifecycles, and user interaction flows.
2. Control flow models – These behavioral models illustrate software behavior through sequences of events, triggers, and messages that cause software processes to be dynamically activated or deactivated over time. Control flows are useful for expressing orchestration and coordination logic.
3. Data flow models – This form represents software behavior in terms of how data moves through various processes, transformations, and mappings in route to its ultimate destination in data stores or data sinks. Data flow modeling helps clarify throughput and signal processing behavior.

Simulation tools provided in many software modeling environments give the software engineer a way to dynamically step through and interactively test behavioral models and prototypes. Being able to visualize and validate the modeled behavior in action helps verify that the software’s different constituent parts work together per the intended interaction design.

Read more about software engineering models and methods in the Software Engineer Book of Knowledge (SWEBOK)

Back to Top

Thorough analysis of the software models created during development is critically important to ensure that the models adequately and accurately serve their intended purpose. The stakeholders who participate in designing, evaluating, or making decisions based on the models need sufficient confidence that the models form a valid basis for those activities.

The model analysis process analyzes the models for desirable characteristics such as completeness, consistency, correctness, traceability, and proper interaction. The goal is to verify that the models exhibit these qualities to a degree necessary to instill confidence in downstream decisions, ensure implementation requirements are met, and reduce the risk of flaws in the deployed software.

Back to Top

Completeness is defined as the degree to which all specified requirements, conditions, features, functions, and other elements have been sufficiently implemented and verified within the scope of the model. In other words, a complete model is one that incorporates or represents all of the relevant requirements in an exhaustive manner.

Analyzing a model for completeness involves checking that the model has addressed all documented requirements and has all of the parts it needs to accurately mirror the full capabilities of the envisioned software under all necessary scenarios. This allows confirmation that no gaps exist.

For models developed using automation-based modeling tools, completeness checks are often accomplished by leveraging analysis functions built into the tools themselves. Two examples are static structural analysis and dynamic state-space reachability analysis. The first examines the integrity of the structural composition while the second explores whether some set of correct input conditions can properly reach all defined paths and endpoints in state-based models.

Manual completeness analysis techniques such as model inspections, desk checking, peer reviews, and walkthroughs are also effective. Subject matter experts analyze the models to look for missing functionality or gaps in requirements coverage based on the documents and specifications.

Back to Top

Consistency refers to the degree to which the software model contains no contradictory, conflicting, or mutually exclusive requirements, assertions, constraints, behaviors, functions, or component characteristics. A consistent model is one where all components work harmoniously.

Analyzing a software model for consistency involves thoroughly checking that the model contains no incompatible or incongruous elements. All requirements, functions, component descriptions, and other modeled entities must cohesively fit together.

Errors and warnings produced during automated analysis or manual reviews signify areas of potential disharmony needing reconciliation to achieve model consistency. Addressing these deficiencies ensures uniformity across the model.

Back to Top

Analyzing a software model for correctness involves investigating and validating that the constructs, components, and behaviors represented in the model accurately satisfy both the software requirements specifications and the software design specifications in an error-free manner. Ultimately, correctness indicates that the model meets the stakeholders’ needs as intended without defect.

Correctness analysis includes two main components:

• Syntactic analysis – This checks that the modeling language (graphical or textual) has been used correctly and the model adheres to the grammar, vocabulary, semantics, and notation rules of the language without error.
• Semantic analysis – This investigates whether the meaning represented by the language constructs used in the model accurately and completely captures the real-world intent.

Syntactic analysis and semantic analysis combined help determine if the model properly reflects both the form and meaning of the software specifications. Automation, such as embedded modeling tool rule checkers, can perform syntactic analysis by scanning for incorrect use of modeling constructs. Semantic issues often require human insight via peer reviews, walkthroughs, and simulation.

Back to Top

Structural modeling is used to illustrate a software application’s physical or logical model from the perspective of its composition, architecture, componentization, and/or organization. A structural model visually establishes the delineation between the software product being modeled and the external environment in which the software is intended to operate.

Some common structural modeling constructs include:

• Hierarchical decomposition and refinement of entities
• Generalization relationships between entities
• Specialization relationships between entities
• Identification of relevant relations between entities and enumeration of cardinality rules
• Definition of external product interfaces, APIs, and exposed services
• Specification of internal process interfaces and inter-process coordination

A specialized form of structural modeling called information modeling focuses specifically on the data perspective and the flow of information within an organization and software solution. Information modeling is used to identify and define important data entities, properties, relations, and constraints, apart from how these will ultimately be physically implemented. The goal is to provide increased formalism and context regarding the informational aspects of the software domain being modeled.

The conceptual or semantic data model formulated through information modeling presents an abstraction of the data and information from the point of view of the problem space rather than the solution space. It includes only those concepts, attributes, relationships, and rules needed to properly conceptualize a real-world view of the information landscape for the organization or business.

Through successive model transformations, the conceptual information model is elaborated into logical data models and, finally, physical data models as the software architecture takes shape. These latter models address how the information will be technically represented and managed within the software solution infrastructure.

Relevant UML structure diagram types that can be used for structural modeling include class, component, object, deployment, and package diagrams. These provide different static structural views of the software architecture and composition.

Back to Top

Software engineering methods provide an organized, systematic approach for specifying, designing, constructing, testing, and verifying the resulting software products and associated work items involved in developing computer software applications. The methods impose a certain structure, set of steps, practices, and procedures on the software engineering effort to make it more methodical, repeatable, and ultimately more success-oriented.

There are numerous software engineering methods available from which to choose when undertaking a development project. When software developers and project teams with the right complementary skill sets employ these methods aided by proper tools and techniques, they are able to visualize the software from varying perspectives and at different levels of abstraction and detail. Understanding the software ecosystem helps drive informed decision-making throughout the engineering process. The methods provide an efficient path to transforming the software representations into a fully functional set of executable code, data stores, interfaces, and operational documentation that collectively deliver value to the end users.

Back to Top

Heuristic methods constitute a category of experience-based software engineering methods that are fairly well-established and widely practiced throughout the software industry. These methods provide rational unified process approaches for developing software using informal sets of “rules of thumb” that have developed over time.

Heuristic software engineering methods do not rely on mathematically rigorous formalism or absolute proofs. Rather, they leverage lessons learned, time-tested strategies, and pragmatic guidelines to structure the development process in an efficient and productive manner.

Some of the most common subcategories of heuristic software engineering methods include:

Structured Analysis and Design – This software development process focuses on systematically developing the software model primarily from a functional, behavioral perspective. The process starts with a high-level architectural view of the software system being built, encompassing major logical control and data elements. Through successive iterations of refinement, the functional components are elaborated and decomposed into increasingly detailed design blueprints. These design details gradually converge to specific software component specifications that can in turn be transformed (by hand, automated tools, or a combination) into coded modules ready for integration.

Data Modeling – In contrast to structured analysis and design techniques, the data modeling approach centers on constructing the logical and physical data model of the software system strictly from the viewpoint of the organizational data and information flows. Data tables, schemas, attributes, relationships, and transactions serve as the basis for defining the models. This data-centric method is used most prominently in business software development life cycle, where data is actively managed as an enterprise systems resource or asset. The resulting data models form the foundation for database designs and persistent data repositories.

Object-Oriented Analysis and Design – The object-oriented analysis and design paradigm represents the software under construction as a network of interacting objects. These objects encapsulate both data persistence and relationships along with behavior in the form of methods that can be invoked to request services from other objects. Objects can represent real-world physical or conceptual entities or purely virtual constructs. Various diagrams and process model views are built using the notation and semantics of the object-oriented modeling language. This high-level representation is iteratively refined into a detailed design capturing all facets required ultimately for code implementation.

Aspect-Oriented Development – This approach seeks to solve the problems of scattering and tangling of crosscutting concerns that naturally arise in complex software system designs. Logging, authentication, transaction management, and data marshaling are examples of functionality that crosscut the traditional modular software decomposition. Aspect-oriented software development methodology proposes decomposing the system into modules representing these crosscutting concerns and keeping them encapsulated from other modules throughout the sdlc model.

Model-Driven and Model-Based Development – Model-driven development (MDD) refers to a software development model in which models are the primary artifacts of the development process. In the most extreme vision of MDD, even executable code could be auto-generated from the models. Model-based development (MBD) implies development in which models still play an important role but are not necessarily the key development artifact. Both MDD and MBD center on evolving incremental model toward implementation.

Back to Top

Formal methods comprise a specialized class of software engineering methods that apply a rigorous, mathematics-based notation and language for specifying, developing, and verifying computer software. They provide an approach to software construction rooted in mathematical proofs and formal logic rather than empirical heuristics.

This category of methods centers around the following key themes and techniques:

Specification Languages – These textual languages allow software specifications and requirements to be expressed in a formal, mathematical notation that removes ambiguity. Examples are Extended BNF (Backus-Naur Form) and Z notation.

Program Refinement and Derivation – The goal here is to create a provably correct software design model through a succession of semantics-preserving transformations from an initial high-level specification.

Formal Verification – An example verification technique is model checking, which performs an exhaustive state-space exploration to verify that a software model design preserves critical properties under all possible scenario paths and conditions.

Logical Inference – This technique enables predicting extreme programming behavior based on axioms and rules of inference rather than executing the software.

Back to Top

• Rapid Prototyping produces incomplete application versions for the sole purpose of eliciting feedback and testing ideas. Prototypes can help teams understand unclear aspects of a proposed product.
• Agile software development processes like extreme programming (XP) incorporate short, iterative cycles, adaptive planning, and continuous improvement to reduce overhead on smaller projects.
• Rapid application development (RAD) enables quickly developing and deploying business applications using case tools.

Back to Top

Software engineering models and methods bring systematization and repeatability to software development, increasing the likelihood of success. Models provide abstraction, perspective, and communication. Structural and behavioral models address different concerns. Analysis verifies whether models are complete, consistent, and correct. A variety of software engineering methods exist, spanning formal mathematical specification to lightweight agile methodology. The methods selected dramatically impact the effectiveness of a project. Careful modeling combined with appropriate engineering methods help ensure software fully meets the needs of stakeholders in a cost-effective manner.

Read more about software engineering models and methods in the Software Engineer Book of Knowledge (SWEBOK)

Back to Top