commit ffe739c92829f51bbac692d12832e7d4bd4e6585 from: Sergey Bronnikov date: Mon Jan 17 17:19:06 2022 UTC Fix formatting in Software Engineering Models Closes #10 commit - a96d3aa5e261a1b854391ddeb9c33fc4873bd36e commit + ffe739c92829f51bbac692d12832e7d4bd4e6585 blob - 4003ce6f611b85882b60ca707bf38ba4f4233516 blob + 689a6b97272c252661df7362dbbb039125c0deb7 --- 9_software_engineering_models.md +++ 9_software_engineering_models.md @@ -1,1084 +1,641 @@ -**CHAPTER 9** +## Chapter 9: Software Engineering Models And Methods -**SOFTWARE ENGINEERING MODELS AND METHODS** +**Acronyms** -##### ACRONYMS +- 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 -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 +**Introduction** -##### INTRODUCTION - 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 com- -plete software life cycle. The emphasis in this knowledge area (KA) is on -software engineer- ing models and methods that encompass multiple software life +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. -##### BREAKDOWN OF TOPICS FOR +BREAKDOWN OF TOPICS FOR SOFTWARE ENGINEERING MODELS AND METHODS -##### SOFTWARE ENGINEERING MODELS +This chapter on software engineering models and methods is divided into four +main topic areas: -##### AND METHODS +- _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. -This chapter on software engineering models and -methods is divided into four main topic areas: +### 1. Modeling -- _Modeling_ : discusses the general practice - of modeling and presents topics in model- - ing principles; properties and expression of - models; modeling syntax, semantics, and - pragmatics; and preconditions, postcondi- - tions, 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 model- - ing to verify completeness, consistency, cor- - rectness, 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 soft- -ware 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 author- -ity, evaluator, developer, software engineer, and +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 con- -cepts that apply in some form to them all. The -following sections provide background on these -general concepts. -_1.1. Modeling Principles_ -[1*, c2s2, c5s1, c5s2] [2*, c2s2] [3*, c5s0] +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. -Modeling provides the software engineer with -an organized and systematic approach for repre- -senting significant aspects of the software under -study, facilitating decision-making about the soft- -ware or elements of it, and communicating those +#### 1.1. Modeling Principles + -significant decisions to others in the stakeholder -communities. There are three general principles -guiding such modeling activities: +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, organiza- - tional view, and other views as relevant). - Organizing information into views focuses - the software modeling efforts on specific +- _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. +![Figure 9.1. Breakdown of Topics for the Software Engineering Models and Methods KA](images/Figure-9.1.png) -Figure 9.1. Breakdown of Topics for the Software Engineering Models and Methods KA +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. -Software Engineering Models and Methods 9-3 +#### 1.2. Properties and Expression of Models -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, mean- - ing within context). When used rigorously - and systematically, this modeling results in - a reporting approach that facilitates effective - communication of software information to - project stakeholders. +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: -A model is an _abstraction_ or simplification of -a software component. A consequence of using -abstraction is that no single abstraction com- -pletely 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, per- -spectives, 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. +- _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. -_1.2. Properties and Expression of Models_ -[1*, c5s2, c5s3] [3*, c4s1.1p7, c4s6p3, -c5s0p3] +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. -Properties of models are those distinguishing fea- -tures 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: +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. -- _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, asser- - tions, constraints, functions, or component - descriptions. -- _Correctness_ : the degree to which the model - satisfies its requirements and design specifi- - cations and is free of defects. +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. +#### 1.3. Syntax, Semantics, and Pragmatics -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 arti- -facts (for example, processors, sensors, or robots) -or abstract artifacts (for example, software mod- -ules or communication protocols). Model enti- -ties are connected to other entities using rela- -tions (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 lan- -guage 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 pre- -cise 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 automa- -tion, models may be checked for completeness -and consistency. The usefulness of these checks -depends greatly on the level of semantic and syn- -tactic rigor applied to the modeling effort in addi- -tion to explicit tool support. Correctness is typi- -cally checked through simulation and/or review. + +Models can be surprisingly deceptive. The fact that a model is an abstraction +with missing information can lead one into a false sense of completely +understanding the software from a single model. A complete model (“complete” +being relative to the modeling effort) may be a union of multiple submodels and +any special function models. Examination and decision-making relative to a +single model within this collection of submodels may be problematic. -1.3. Syntax, Semantics, and Pragmatics -[2* c2s2.2.2p6] [3*, c5s0] +Understanding the precise meanings of modeling constructs can also be +difficult. Modeling languages are defined by syntactic and semantic rules. For +textual languages, syntax is defined using a notation grammar that defines +valid language constructs (for example, Backus-Naur Form (BNF)). For graphical +languages, syntax is defined using graphical models called metamod- els. As +with BNF, metamodels define the valid syntactical constructs of a graphical +modeling language; the metamodel defines how these constructs can be composed +to produce valid models. Semantics for modeling languages specify the meaning +attached to the entities and relations captured within the model. For example, +a simple diagram of two boxes connected by a line is open to a variety of +interpretations. Knowing that the diagram on which the boxes are placed and +connected is an object diagram or an activity diagram can assist in the +interpretation of this model. +As a practical matter, there is usually a good understanding of the semantics +of a specific software model due to the modeling language selected, how that +modeling language is used to express entities and relations within that model, +the experience base of the modeler(s), and the context within which the +modeling has been undertaken and so represented. Meaning is communicated +through the model even in the presence of incomplete information through +abstraction; pragmatics explains how meaning is embodied in the model and its +context and communicated effectively to other software engineers. -Models can be surprisingly deceptive. The fact -that a model is an abstraction with missing infor- -mation can lead one into a false sense of com- -pletely understanding the software from a single -model. A complete model (“complete” being -relative to the modeling effort) may be a union -of multiple submodels and any special function -models. Examination and decision-making rela- -tive to a single model within this collection of -submodels may be problematic. -Understanding the precise meanings of mod- -eling constructs can also be difficult. Modeling -languages are defined by syntactic and semantic -rules. For textual languages, syntax is defined -using a notation grammar that defines valid lan- -guage constructs (for example, Backus-Naur -Form (BNF)). For graphical languages, syntax is -defined using graphical models called metamod- -els. As with BNF, metamodels define the valid -syntactical constructs of a graphical modeling -language; the metamodel defines how these con- -structs can be composed to produce valid models. -Semantics for modeling languages specify the -meaning attached to the entities and relations -captured within the model. For example, a simple -diagram of two boxes connected by a line is open -to a variety of interpretations. Knowing that the -diagram on which the boxes are placed and con- -nected is an object diagram or an activity diagram -can assist in the interpretation of this model. -As a practical matter, there is usually a good -understanding of the semantics of a specific -software model due to the modeling language -selected, how that modeling language is used to -express entities and relations within that model, -the experience base of the modeler(s), and the -context within which the modeling has been -undertaken and so represented. Meaning is com- -municated through the model even in the presence -of incomplete information through abstraction; -pragmatics explains how meaning is embodied -in the model and its context and communicated -effectively to other software engineers. -There are still instances, however, where cau- -tion is needed regarding modeling and semantics. -For example, any model parts imported from -another model or library must be examined for -semantic assumptions that conflict in the new -modeling environment; this may not be obvious. -The model should be checked for documented -assumptions. While modeling syntax may be -identical, the model may mean something quite -different in the new environment, which is a dif- -ferent context. Also, consider that as software -matures and changes are made, semantic discord +There are still instances, however, where caution is needed regarding +modeling and semantics. For example, any model parts imported from another +model or library must be examined for semantic assumptions that conflict in the +new modeling environment; this may not be obvious. The model should be checked +for documented assumptions. While modeling syntax may be identical, the model +may mean something quite different in the new environment, which is a dif- +ferent context. Also, consider that as software matures and changes are +made, semantic discord can be introduced, leading to errors. With many +software engineers working on a model part over time coupled with tool +updates and perhaps new requirements, there are opportunities for portions +of the model to represent something different from the original author’s +intent and initial model context. +#### 1.4. Preconditions, Postconditions, and Invariants -can be introduced, leading to errors. With many -software engineers working on a model part over -time coupled with tool updates and perhaps new -requirements, there are opportunities for portions -of the model to represent something different -from the original author’s intent and initial model -context. + +When modeling functions or methods, the software engineer typically starts +with a set of assumptions about the state of the software prior to, during, and +after the function or method executes. These assumptions are essential to the +correct operation of the function or method and are grouped, for discussion, +as a set of preconditions, postconditions, and invariants. -1.4. Preconditions, Postconditions, and -Invariants -[2*, c4s4] [4*, c10s4p2, c10s5p2p4] +- _Preconditions_: a set of conditions that must be satisfied prior to + execution of the function or method. If these preconditions do not hold prior + to execution of the function or method, the function or method may produce + erroneous results. +- _Postconditions_: a set of conditions that is guaranteed to be true after + the function or method has executed successfully. Typically, the + postconditions represent how the state of the software has changed, how + parameters passed to the function or method have changed, how data values + have changed, or how the return value has been affected. +- _Invariants_: a set of conditions within the operational environment that + persist (in other words, do not change) before and after execution of the + function or method. These invariants are relevant and necessary to the + software and the correct operation of the function or method. +### 2. Types of Models -When modeling functions or methods, the soft- -ware engineer typically starts with a set of -assumptions about the state of the software prior -to, during, and after the function or method exe- -cutes. These assumptions are essential to the cor- -rect operation of the function or method and are -grouped, for discussion, as a set of preconditions, -postconditions, and invariants. +A typical model consists of an aggregation of submodels. Each submodel is a +partial description and is created for a specific purpose; it may be +comprised of one or more diagrams. The collection of submodels may employ +multiple modeling languages or a single modeling language. The Unified +Modeling Language (UML) recognizes a rich collection of modeling diagrams. +Use of these diagrams, along with the modeling language constructs, brings +about three broad model types commonly used: information models, behavioral +models, and structure models (see section 1.1). -- _Preconditions_ : a set of conditions that must - be satisfied prior to execution of the function - or method. If these preconditions do not hold - prior to execution of the function or method, - the function or method may produce errone- - ous results. -- _Postconditions_ : a set of conditions that is - guaranteed to be true after the function or - method has executed successfully. Typically, - the postconditions represent how the state - of the software has changed, how param- - eters passed to the function or method have - changed, how data values have changed, or - how the return value has been affected. -- _Invariants_ : a set of conditions within the - operational environment that persist (in - other words, do not change) before and after - execution of the function or method. These - invariants are relevant and necessary to the - software and the correct operation of the - function or method. -**2. Types of Models** +#### 2.1. Information Modeling + -A typical model consists of an aggregation of -submodels. Each submodel is a partial descrip- -tion and is created for a specific purpose; it may -be comprised of one or more diagrams. The -collection of submodels may employ multiple +Information models provide a central focus on data and information. An +information model is an abstract representation that identifies and defines a +set of concepts, properties, relations, and constraints on data entities. The +semantic or conceptual information model is often used to provide some +formalism and context to the software being modeled as viewed from the problem +perspective, without concern for how this model is actually mapped to the +implementation of the software. The semantic or conceptual information model is +an abstraction and, as such, includes only the concepts, properties, relations, +and constraints needed to conceptualize the real-world view of the information. +Subsequent transformations of the semantic or conceptual information model lead +to the elaboration of logical and then physical data models as implemented in +the software. +#### 2.2. Behavioral Modeling + -Software Engineering Models and Methods 9-5 +Behavioral models identify and define the functions of the software being +modeled. Behavioral models generally take three basic forms: state machines, +control-flow models, and dataflow models. State machines provide a model of +the software as a collection of defined states, events, and transitions. The +software transitions from one state to the next by way of a guarded or +unguarded triggering event that occurs in the modeled environment. Control-flow +models depict how a sequence of events causes processes to be activated or +deactivated. Data-flow behavior is typified as a sequence of steps where data +moves through processes toward data stores or data sinks. -modeling languages or a single modeling lan- -guage. The Unified Modeling Language (UML) -recognizes a rich collection of modeling dia- -grams. Use of these diagrams, along with the -modeling language constructs, brings about three -broad model types commonly used: information -models, behavioral models, and structure models -(see section 1.1). +#### 2.3. Structure Modeling -_2.1. Information Modeling_ -[1*, c7s2.2] [3*, c8s1] + -Information models provide a central focus on -data and information. An information model is an -abstract representation that identifies and defines -a set of concepts, properties, relations, and con- -straints on data entities. The semantic or concep- -tual information model is often used to provide -some formalism and context to the software being -modeled as viewed from the problem perspective, -without concern for how this model is actually -mapped to the implementation of the software. -The semantic or conceptual information model -is an abstraction and, as such, includes only the -concepts, properties, relations, and constraints -needed to conceptualize the real-world view of -the information. Subsequent transformations of -the semantic or conceptual information model -lead to the elaboration of logical and then physi- -cal data models as implemented in the software. +Structure models illustrate the physical or logical composition of software +from its various component parts. Structure modeling establishes the defined +boundary between the software being implemented or modeled and the environment +in which it is to operate. Some common structural constructs used in +structure modeling are composition, decomposition, generalization, and +specialization of entities; identification of relevant relations and +cardinality between entities; and the definition of process or functional +interfaces. Structure diagrams provided by the UML for structure modeling +include class, component, object, deployment, and packaging diagrams. -_2.2. Behavioral Modeling_ -[1*, c7s2.1, c7s2.3, c7s2.4] [2*, c9s2] -[3*, c5s4] +### 3. Analysis of Models -Behavioral models identify and define the func- -tions of the software being modeled. Behav- -ioral models generally take three basic forms: -state machines, control-flow models, and data- -flow models. State machines provide a model -of the software as a collection of defined states, -events, and transitions. The software transitions -from one state to the next by way of a guarded -or unguarded triggering event that occurs in the -modeled environment. Control-flow models -depict how a sequence of events causes processes -to be activated or deactivated. Data-flow behav- -ior is typified as a sequence of steps where data -moves through processes toward data stores or -data sinks. +The development of models affords the software engineer an opportunity to +study, reason about, and understand the structure, function, operational +usage, and assembly considerations associated with software. Analysis of +constructed models is needed to ensure that these models are complete, +consistent, and correct enough to serve their intended purpose for the +stakeholders. +The sections that follow briefly describe the analysis techniques generally +used with software models to ensure that the software engineer and other +relevant stakeholders gain appropriate value from the development and use of +models. -2.3. Structure Modeling -[1*, c7s2.5, c7s3.1, c7s3.2] [3*, c5s3] [4*, c4] +#### 3.1. Analyzing for Completeness + -Structure models illustrate the physical or logical -composition of software from its various com- -ponent parts. Structure modeling establishes the -defined boundary between the software being -implemented or modeled and the environment -in which it is to operate. Some common struc- -tural constructs used in structure modeling are -composition, decomposition, generalization, and -specialization of entities; identification of rel- -evant relations and cardinality between entities; -and the definition of process or functional inter- -faces. Structure diagrams provided by the UML -for structure modeling include class, component, -object, deployment, and packaging diagrams. +In order to have software that fully meets the needs of the stakeholders, +completeness is critical - from the requirements elicitation process to code +implementation. Completeness is the degree to which all of the specified +requirements have been implemented and verified. Models may be checked for +completeness by a modeling tool that uses techniques such as structural +analysis and state-space reachability analysis (which ensure that all paths in +the state models are reached by some set of correct inputs); models may also be +checked for completeness manually by using inspections or other review +techniques (see the Software Quality KA). Errors and warnings generated by +these analysis tools and found by inspection or review indicate probable needed +corrective actions to ensure completeness of the models. -**3. Analysis of Models** +#### 3.2. Analyzing for Consistency + -The development of models affords the software -engineer an opportunity to study, reason about, -and understand the structure, function, opera- -tional usage, and assembly considerations asso- -ciated with software. Analysis of constructed -models is needed to ensure that these models are -complete, consistent, and correct enough to serve -their intended purpose for the stakeholders. -The sections that follow briefly describe the -analysis techniques generally used with soft- -ware models to ensure that the software engineer -and other relevant stakeholders gain appropriate -value from the development and use of models. +Consistency is the degree to which models contain no conflicting +requirements, assertions, constraints, functions, or component descriptions. +Typically, consistency checking is accomplished with the modeling tool using an +automated analysis function; models may also be checked for consistency +manually using inspections or other review techniques (see the Software Quality +KA). As with completeness, errors and warnings generated by these analysis +tools and found by inspection or review indicate the need for corrective +action. +#### 3.3. Analyzing for Correctness -3.1. Analyzing for Completeness -[3*, c4s1.1p7, c4s6] [5*, p8–11] + +Correctness is the degree to which a model satisfies its software +requirements and software design specifications, is free of defects, and ulti- +mately meets the stakeholders’ needs. Analyzing for correctness includes +verifying syntactic correctness of the model (that is, correct use of the +modeling language grammar and constructs) and verifying semantic correctness of +the model (that is, use of the modeling language constructs to correctly +represent the meaning of that which is being modeled). To analyze a model for +syntactic and semantic correctness, one analyzes it - either automatically (for +example, using the modeling tool to check for model syntactic correctness) or +manually (using inspections or other review techniques) - searching for possible +defects and then removing or repairing the confirmed defects before the +software is released for use. -In order to have software that fully meets the needs -of the stakeholders, completeness is critical—from -the requirements elicitation process to code imple- -mentation. Completeness is the degree to which -all of the specified requirements have been imple- -mented and verified. Models may be checked for -completeness by a modeling tool that uses tech- -niques such as structural analysis and state-space -reachability analysis (which ensure that all paths in -the state models are reached by some set of correct -inputs); models may also be checked for complete- -ness manually by using inspections or other review -techniques (see the Software Quality KA). Errors -and warnings generated by these analysis tools and -found by inspection or review indicate probable -needed corrective actions to ensure completeness -of the models. +#### 3.4. Traceability -_3.2. Analyzing for Consistency_ -[3*, c4s1.1p7, c4s6] [5*, p8–11] + -Consistency is the degree to which models con- -tain no conflicting requirements, assertions, con- -straints, functions, or component descriptions. -Typically, consistency checking is accomplished -with the modeling tool using an automated analysis -function; models may also be checked for consis- -tency manually using inspections or other review -techniques (see the Software Quality KA). As -with completeness, errors and warnings generated -by these analysis tools and found by inspection or -review indicate the need for corrective action. +Developing software typically involves the use, creation, and modification of +many work products such as planning documents, process specifications, +software requirements, diagrams, designs and pseudo-code, handwritten and +tool-generated code, manual and automated test cases and reports, and files and +data. These work products may be related through various dependency +relationships (for example, uses, implements, and tests). As software is +being developed, managed, maintained, or extended, there is a need to map and +control these traceability relationships to demonstrate software requirements +consistency with the software model (see Requirements Tracing in the Software +Requirements KA) and the many work products. -_3.3. Analyzing for Correctness_ -[5*, p8–11] +Use of traceability typically improves the management of software work products +and software process quality; it also provides assurances to stakeholders that +all requirements have been satisfied. Traceability enables change analysis once +the software is developed and released, since relationships to software work +products can easily be traversed to assess change impact. Modeling tools +typically provide some automated or manual means to specify and manage +traceability links between requirements, design, code, and/or test entities +as may be represented in the models and other software work products. (For more +information on traceability, see the Software Configuration Management KA). -Correctness is the degree to which a model sat- -isfies its software requirements and software -design specifications, is free of defects, and ulti- -mately meets the stakeholders’ needs. Analyzing -for correctness includes verifying syntactic cor- -rectness of the model (that is, correct use of the -modeling language grammar and constructs) and -verifying semantic correctness of the model (that -is, use of the modeling language constructs to -correctly represent the meaning of that which is -being modeled). To analyze a model for syntactic -and semantic correctness, one analyzes it—either -automatically (for example, using the modeling -tool to check for model syntactic correctness) -or manually (using inspections or other review -techniques)—searching for possible defects and -then removing or repairing the confirmed defects -before the software is released for use. +#### 3.5. Interaction Analysis -_3.4. Traceability_ -[3*, c4s7.1, c4s7.2] + -Developing software typically involves the use, -creation, and modification of many work products -such as planning documents, process specifica- -tions, software requirements, diagrams, designs +Interaction analysis focuses on the communications or control flow relations +between entities used to accomplish a specific task or function within the +software model. This analysis examines the dynamic behavior of the interactions +between different portions of the software model, including other software +layers (such as the operating system, middleware, and applications). It may +also be important for some software applications to examine interactions +between the computer software application and the user interface software. Some +software modeling environments provide simulation facilities to study aspects +of the dynamic behavior of modeled software. Stepping through the simulation +provides an analysis option for the software engineer to review the interaction +design and verify that the different parts of the software work together to +provide the intended functions. +### 4. Software Engineering Methods -and pseudo-code, handwritten and tool-generated -code, manual and automated test cases and reports, -and files and data. These work products may be -related through various dependency relationships -(for example, uses, implements, and tests). As soft- -ware is being developed, managed, maintained, or -extended, there is a need to map and control these -traceability relationships to demonstrate soft- -ware requirements consistency with the software -model (see Requirements Tracing in the Software -Requirements KA) and the many work products. -Use of traceability typically improves the manage- -ment of software work products and software pro- -cess quality; it also provides assurances to stake- -holders that all requirements have been satisfied. -Traceability enables change analysis once the soft- -ware is developed and released, since relationships -to software work products can easily be traversed -to assess change impact. Modeling tools typically -provide some automated or manual means to spec- -ify and manage traceability links between require- -ments, design, code, and/or test entities as may be -represented in the models and other software work -products. (For more information on traceability, -see the Software Configuration Management KA). +Software engineering methods provide an organized and systematic approach to +developing software for a target computer. There are numerous methods from +which to choose, and it is important for the software engineer to choose an +appropriate method or methods for the software development task at hand; this +choice can have a dramatic effect on the success of the software project. Use +of these software engineering methods coupled with people of the right skill +set and tools enable the software engineers to visualize the details of the +software and ultimately transform the representation into a working set of code +and data. +Selected software engineering methods are discussed below. The topic areas +are organized into discussions of Heuristic Methods, Formal Methods, +Prototyping Methods, and Agile Methods. -3.5. Interaction Analysis -[2*, c10, c11] [3*, c29s1.1, c29s5] [4*, c5] +#### 4.1. Heuristic Methods + + + +Heuristic methods are those experience-based software engineering methods that +have been and are fairly widely practiced in the software industry. This +topic area contains three broad discussion categories: structured analysis +and design methods, data modeling methods, and object-oriented analysis and +design methods. + +- _Structured Analysis and Design Methods_: The software model is developed + primarily from a functional or behavioral viewpoint, starting from a + high-level view of the software (including data and control elements) and + then progressively decomposing or refining the model components through + increasingly detailed designs. The detailed design eventually converges to + very specific details or specifications of the software that must be coded + (by hand, automatically generated, or both), built, tested, and verified. +- _Data Modeling Methods_: The data model is constructed from the viewpoint of + the data or information used. Data tables and relationships define the data + models. This data modeling method is used primarily for defining and + analyzing data requirements supporting database designs or data repositories + typically found in business software, where data is actively managed as a + business systems resource or asset. +- _Object-Oriented Analysis and Design Methods_: The object-oriented model is + represented as a collection of objects that encapsulate data and + relationships and interact with other objects through methods. Objects may be + real-world items or virtual items. The software model is constructed using + diagrams to constitute selected views of the software. Progressive refinement + of the software models leads to a detailed design. The detailed design is + then either evolved through successive iteration or transformed (using some + mechanism) into the implementation view of the model, where the code and + packaging approach for eventual software product release and deployment is + expressed. +#### 4.2. Formal Methods -Interaction analysis focuses on the communica- -tions or control flow relations between entities -used to accomplish a specific task or function -within the software model. This analysis exam- -ines the dynamic behavior of the interactions -between different portions of the software model, -including other software layers (such as the oper- -ating system, middleware, and applications). It -may also be important for some software applica- -tions to examine interactions between the com- -puter software application and the user interface -software. Some software modeling environments -provide simulation facilities to study aspects of -the dynamic behavior of modeled software. Step- -ping through the simulation provides an analysis -option for the software engineer to review the -interaction design and verify that the different -parts of the software work together to provide the -intended functions. + +Formal methods are software engineering methods used to specify, develop, and +verify the software through application of a rigorous mathematically based +notation and language. Through use of a specification language, the software +model can be checked for consistency (in other words, lack of ambiguity), +completeness, and correctness in a systematic and automated or semi-automated +fashion. This topic is related to the Formal Analysis section in the Software +Requirements KA. +This section addresses specification languages, program refinement and +derivation, formal verification, and logical inference. -Software Engineering Models and Methods 9-7 +- _Specification Languages_: Specification languages provide the mathematical + basis for a formal method; specification lan- guages are formal, higher level + computer languages (in other words, not a classic 3rd Generation Language + (3GL) program- ming language) used during the software specification, + requirements analysis, and/ or design stages to describe specific input/ + output behavior. Specification languages are not directly executable + languages; they are typically comprised of a notation and syntax, semantics + for use of the notation, and a set of allowed relations for objects. +- _Program Refinement and Derivation_: Program refinement is the process of + creating a lower level (or more detailed) specification using a series of + transformations. It is through successive transformations that the software + engineer derives an executable representation of a program. Specifications + may be refined, adding details until the model can be formulated in a 3GL + programming language or in an executable portion of the chosen specifica- + tion language. This specification refinement is made possible by defining + specifications with precise semantic properties; the specifications must set + out not only the relationships between entities but also the exact runtime + meanings of those relationships and operations. +- _Formal Verification_: Model checking is a formal verification method; it + typically involves performing a state-space exploration or reachability + analysis to demonstrate that the represented software design has or preserves + certain model properties of interest. An example of model checking is an + analysis that verifies correct program behavior under all possible + interleaving of event or message arrivals. The use of formal verification + requires a rigorously specified model of the software and its operational + environment; this model often takes the form of a finite state machine or + other formally defined automaton. +- _Logical Inference_: Logical inference is a method of designing software + that involves specifying preconditions and postconditions around each + significant block of the design, and - using mathematical logic - developing the + proof that those preconditions and postconditions must hold under all + inputs. This provides a way for the software engineer to predict software + behavior without having to execute the software. Some Integrated Development + Environments (IDEs) include ways to represent these proofs along with the + design or code. -**4. Software Engineering Methods** +#### 4.3. Prototyping Methods -Software engineering methods provide an orga- -nized and systematic approach to developing soft- -ware for a target computer. There are numerous -methods from which to choose, and it is important -for the software engineer to choose an appropriate -method or methods for the software development -task at hand; this choice can have a dramatic effect -on the success of the software project. Use of these -software engineering methods coupled with people -of the right skill set and tools enable the software -engineers to visualize the details of the software -and ultimately transform the representation into a -working set of code and data. -Selected software engineering methods are dis- -cussed below. The topic areas are organized into -discussions of Heuristic Methods, Formal Meth- -ods, Prototyping Methods, and Agile Methods. + -_4.1. Heuristic Methods_ -[1*, c13, c15, c16] [3*, c2s2.2, c5s4.1, c7s1,] +Software prototyping is an activity that generally creates incomplete or +minimally functional versions of a software application, usually for trying +out specific new features, soliciting feedback on software requirements or user +interfaces, further exploring software requirements, software design, or +implementation options, and/or gaining some other useful insight into the +software. The software engineer selects a prototyping method to understand the +least understood aspects or components of the software first; this approach +is in contrast with other software engineering methods that usually begin +development with the most understood portions first. Typically, the proto- +typed product does not become the final software product without extensive +development rework or refactoring. -Heuristic methods are those experience-based -software engineering methods that have been and -are fairly widely practiced in the software indus- -try. This topic area contains three broad discus- -sion categories: structured analysis and design -methods, data modeling methods, and object- -oriented analysis and design methods. +This section discusses prototyping styles, targets, and evaluation techniques +in brief. -- _Structured Analysis and Design Methods_ : - The software model is developed primarily - from a functional or behavioral viewpoint, - starting from a high-level view of the soft- - ware (including data and control elements) - and then progressively decomposing or refin- - ing the model components through increas- - ingly detailed designs. The detailed design - eventually converges to very specific details - or specifications of the software that must be - coded (by hand, automatically generated, or - both), built, tested, and verified. -- _Data Modeling Methods_ : The data model is - constructed from the viewpoint of the data or - information used. Data tables and relation- - ships define the data models. This data mod- - eling method is used primarily for defining - and analyzing data requirements supporting +- _Prototyping Style_: This addresses the various approaches to developing + prototypes. Prototypes can be developed as throwaway code or paper + products, as an evolution of a working design, or as an executable + specification. Different prototyping life cycle processes are typically used + for each style. The style chosen is based on the type of results the + project needs, the quality of the results needed, and the urgency of the + results. +- _Prototyping Target_: The target of the prototype activity is the specific + product being served by the prototyping effort. Examples of prototyping + targets include a requirements specification, an architectural design element + or component, an algorithm, or a human-machine user interface. +- _Prototyping Evaluation Techniques_: A prototype may be used or evaluated + in a number of ways by the software engineer or other project stakeholders, + driven primarily by the underlying reasons that led to prototype development + in the first place. Prototypes may be evaluated or tested against the actual + implemented software or against a target set of requirements (for example, a + requirements prototype); the prototype may also serve as a model for a future + software development effort (for example, as in a user interface + specification). +#### 4.4. Agile Methods -database designs or data repositories typi- -cally found in business software, where data -is actively managed as a business systems -resource or asset. + -- _Object-Oriented Analysis and Design Meth-_ - _ods_ : The object-oriented model is represented - as a collection of objects that encapsulate - data and relationships and interact with other - objects through methods. Objects may be - real-world items or virtual items. The soft- - ware model is constructed using diagrams - to constitute selected views of the software. - Progressive refinement of the software mod- - els leads to a detailed design. The detailed - design is then either evolved through suc- - cessive iteration or transformed (using some - mechanism) into the implementation view - of the model, where the code and packag- - ing approach for eventual software product - release and deployment is expressed. +Agile methods were born in the 1990s from the need to reduce the apparent large +overhead associated with heavyweight, plan-based methods used in large-scale +software-development projects. Agile methods are considered lightweight meth- +ods in that they are characterized by short, iterative development cycles, +self-organizing teams, simpler designs, code refactoring, test-driven +development, frequent customer involvement, and an emphasis on creating a +demonstrable working product with each development cycle. +Many agile methods are available in the literature; some of the more popular +approaches, which are discussed here in brief, include Rapid Application +Development (RAD), eXtreme Programming (XP), Scrum, and Feature-Driven +Development (FDD). -4.2. Formal Methods -[1*, c18] [3*, c27] [5*, p8–24] +- _RAD:_ Rapid software development methods are used primarily in + data-intensive, business-systems application development. The RAD method is + enabled with special-purpose database development tools used by software + engineers to quickly develop, test, and deploy new or modified business + applications. +- _XP_: This approach uses stories or scenarios for requirements, develops + tests first, has direct customer involvement on the team (typically defining + acceptance tests), uses pair programming, and provides for continuous code + refactoring and integration. Stories are decomposed into tasks, prioritized, + estimated, developed, and tested. Each increment of software is tested + with automated and manual tests; an increment may be released frequently, + such as every couple of weeks or so. +- _Scrum_: This agile approach is more project management-friendly than the + others. The scrum master manages the activities within the project increment; + each increment is called a sprint and lasts no more than 30 days. A Product + Backlog Item (PBI) list is developed from which tasks are identified, + defined, prioritized, and estimated. A working version of the software is + tested and released in each increment. Daily scrum meetings ensure work is + managed to plan. +- _FDD:_ This is a model-driven, short, iterative software development + approach using a five-phase process: (1) develop a product model to scope the + breadth of the domain, (2) create the list of needs or features, (3) build + the feature development plan, (4) develop designs for iteration-specific + features, and (5) code, test, and then integrate the features. FDD is similar + to an incremental software development approach; it is also similar to XP, + except that code ownership is assigned to individuals rather than the team. + FDD emphasizes an overall architectural approach to the software, which + promotes building the feature correctly the first time rather than + emphasizing continual refactoring. +There are many more variations of agile methods in the literature and in +practice. Note that there will always be a place for heavyweight, plan-based +software engineering methods as well as places where agile methods shine. There +are new methods arising from combinations of agile and plan-based methods where +practitioners are defining new methods that balance the features needed in both +heavyweight and lightweight methods based primarily on prevailing +organizational business needs. These business needs, as typically represented +by some of the project stakeholders, should and do drive the choice in using +one software engineering method over another or in constructing a new method +from the best features of a combination of software engineering methods. -Formal methods are software engineering meth- -ods used to specify, develop, and verify the soft- -ware through application of a rigorous mathemat- -ically based notation and language. Through use -of a specification language, the software model -can be checked for consistency (in other words, -lack of ambiguity), completeness, and correctness -in a systematic and automated or semi-automated -fashion. This topic is related to the Formal Analy- -sis section in the Software Requirements KA. -This section addresses specification languages, -program refinement and derivation, formal verifi- -cation, and logical inference. +### Matrix Of Topics vs. Reference Material -- _Specification Languages_ : Specification - languages provide the mathematical basis - for a formal method; specification lan- - guages are formal, higher level computer - languages (in other words, not a classic - 3rd Generation Language (3GL) program- - ming language) used during the software - specification, requirements analysis, and/ - or design stages to describe specific input/ - output behavior. Specification languages are - not directly executable languages; they are -typically comprised of a notation and syntax, -semantics for use of the notation, and a set of -allowed relations for objects. +Budgen 2003 [1] +Mellor and Balcer 2002 [2] +Sommerville 2011 [3] +Page-Jones 1999 [4] +Wing 1990 [5] +Brookshear 2008 [6] +Boehm and Turner 2003 [7] -- _Program Refinement and Derivation_ : Pro- - gram refinement is the process of creating a - lower level (or more detailed) specification - using a series of transformations. It is through - successive transformations that the software - engineer derives an executable representation - of a program. Specifications may be refined, - adding details until the model can be formu- - lated in a 3GL programming language or in - an executable portion of the chosen specifica- - tion language. This specification refinement is - made possible by defining specifications with - precise semantic properties; the specifications - must set out not only the relationships between - entities but also the exact runtime meanings of - those relationships and operations. -- _Formal Verification_ : Model checking is - a formal verification method; it typically - involves performing a state-space explora- - tion or reachability analysis to demonstrate - that the represented software design has or - preserves certain model properties of inter- - est. An example of model checking is an - analysis that verifies correct program behav- - ior under all possible interleaving of event or - message arrivals. The use of formal verifi- - cation requires a rigorously specified model - of the software and its operational environ- - ment; this model often takes the form of a - finite state machine or other formally defined - automaton. -- _Logical Inference_ : Logical inference is a - method of designing software that involves - specifying preconditions and postconditions - around each significant block of the design, - and—using mathematical logic—developing - the proof that those preconditions and post- - conditions must hold under all inputs. This - provides a way for the software engineer to - predict software behavior without having - to execute the software. Some Integrated - Development Environments (IDEs) include - ways to represent these proofs along with the - design or code. +1. Modeling +1.1. Modeling Principles c2s2, c5s1, c5s2 c2s2 c5s0 +1.2. Properties and Expression of Models c5s2, c5s3 c4s1.1p7, c4s6p3, c5s0p3 +1.3. Syntax, Semantics, and Pragmatics c2s2.2.2 p6 c5s0 +1.4. Preconditions, Postconditions, and Invariants c4s4 c10s4p2, c10s5 p2p4 +2. Types of Models +2.1. Information Modeling c7s2.2 c8s1 +2.2. Behavioral Modeling c7s2.1, c7s2.3, c7s2.4 c9s2 c5s4 +2.3. Structure Modeling c7s2.5, c7s3.1, c7s3.2 c5s3 c4 +3. Analysis of Models +3.1. Analyzing for Completeness c4s1.1p7, c4s6 pp8–11 +3.2. Analyzing for Consistency c4s1.1p7, c4s6 pp8–11 +3.3. Analyzing for Correctness pp8–11 +3.4. Traceability c4s7.1, c4s7.2 +3.5. Interaction Analysis c10, c11 c29s1.1, c29s5 c5 +Budgen 2003 [1] +Mellor and Balcer 2002 [2] +Sommerville 2011 [3] +Page-Jones 1999 [4] +Wing 1990 [5] +Brookshear 2008 [6] +Boehm and Turner 2003 [7] -4.3. Prototyping Methods -[1*, c12s2] [3*, c2s3.1] [6*, c7s3p5] +4. Software Engineering Methods +4.1. Heuristic Methods c13, c15, c16 c2s2.2, c7s1, c5s4.1 +4.2. Formal Methods c18 c27 pp8–24 +4.3. Prototyping Methods c12s2 c2s3.1 c7s3p5 +4.4. Agile Methods c3 c7s3p7 c6, app. A +**References** -Software prototyping is an activity that generally -creates incomplete or minimally functional ver- -sions of a software application, usually for try- -ing out specific new features, soliciting feedback -on software requirements or user interfaces, fur- -ther exploring software requirements, software -design, or implementation options, and/or gaining -some other useful insight into the software. The -software engineer selects a prototyping method to -understand the least understood aspects or com- -ponents of the software first; this approach is in -contrast with other software engineering methods -that usually begin development with the most -understood portions first. Typically, the proto- -typed product does not become the final software -product without extensive development rework -or refactoring. -This section discusses prototyping styles, tar- -gets, and evaluation techniques in brief. +[1] D. Budgen, _Software Design_, 2nd ed., Addison-Wesley, 2003. -- _Prototyping Style_ : This addresses the various - approaches to developing prototypes. Proto- - types can be developed as throwaway code - or paper products, as an evolution of a work- - ing design, or as an executable specification. - Different prototyping life cycle processes are - typically used for each style. The style cho- - sen is based on the type of results the project - needs, the quality of the results needed, and - the urgency of the results. -- _Prototyping Target_ : The target of the pro- - totype activity is the specific product being - served by the prototyping effort. Examples - of prototyping targets include a requirements - specification, an architectural design element - or component, an algorithm, or a human- - machine user interface. -- _Prototyping Evaluation Techniques_ : A pro- - totype may be used or evaluated in a num- - ber of ways by the software engineer or - other project stakeholders, driven primarily - by the underlying reasons that led to pro- - totype development in the first place. Pro- - totypes may be evaluated or tested against - the actual implemented software or against - - - -Software Engineering Models and Methods 9-9 - - -a target set of requirements (for example, a -requirements prototype); the prototype may -also serve as a model for a future software -development effort (for example, as in a user -interface specification). - -_4.4. Agile Methods_ -[3*, c3] [6*, c7s3p7] [7*, c6, App. A] - -Agile methods were born in the 1990s from the -need to reduce the apparent large overhead associ- -ated with heavyweight, plan-based methods used -in large-scale software-development projects. -Agile methods are considered lightweight meth- -ods in that they are characterized by short, itera- -tive development cycles, self-organizing teams, -simpler designs, code refactoring, test-driven -development, frequent customer involvement, and -an emphasis on creating a demonstrable working -product with each development cycle. -Many agile methods are available in the lit- -erature; some of the more popular approaches, -which are discussed here in brief, include Rapid -Application Development (RAD), eXtreme Pro- -gramming (XP), Scrum, and Feature-Driven -Development (FDD). - -- _RAD:_ Rapid software development methods - are used primarily in data-intensive, business- - systems application development. The RAD - method is enabled with special-purpose data- - base development tools used by software - engineers to quickly develop, test, and deploy - new or modified business applications. -- _XP_ : This approach uses stories or scenarios - for requirements, develops tests first, has - direct customer involvement on the team - (typically defining acceptance tests), uses - pair programming, and provides for continu- - ous code refactoring and integration. Stories - are decomposed into tasks, prioritized, esti- - mated, developed, and tested. Each incre- - ment of software is tested with automated - and manual tests; an increment may be - released frequently, such as every couple of - weeks or so. - - _Scrum_ : This agile approach is more project - management-friendly than the others. The - scrum master manages the activities within - the project increment; each increment is - called a sprint and lasts no more than 30 - days. A Product Backlog Item (PBI) list is - developed from which tasks are identified, - defined, prioritized, and estimated. A work- - ing version of the software is tested and - released in each increment. Daily scrum - meetings ensure work is managed to plan. - - _FDD:_ This is a model-driven, short, itera- - tive software development approach using - a five-phase process: (1) develop a product - model to scope the breadth of the domain, (2) - create the list of needs or features, (3) build - the feature development plan, (4) develop - designs for iteration-specific features, and - (5) code, test, and then integrate the features. - FDD is similar to an incremental software - development approach; it is also similar to - XP, except that code ownership is assigned - to individuals rather than the team. FDD - emphasizes an overall architectural approach - to the software, which promotes building the - feature correctly the first time rather than - emphasizing continual refactoring. - - -There are many more variations of agile meth- -ods in the literature and in practice. Note that -there will always be a place for heavyweight, -plan-based software engineering methods as well -as places where agile methods shine. There are -new methods arising from combinations of agile -and plan-based methods where practitioners are -defining new methods that balance the features -needed in both heavyweight and lightweight -methods based primarily on prevailing organi- -zational business needs. These business needs, -as typically represented by some of the project -stakeholders, should and do drive the choice in -using one software engineering method over -another or in constructing a new method from the -best features of a combination of software engi- -neering methods. - - -##### MATRIX OF TOPICS VS. REFERENCE MATERIAL - - -Budgen 2003 - -##### [1] - - -Mellor and Balcer 2002 - -##### [2] - - -Sommerville 2011 - -##### [3] - - -Page-Jones 1999 - -##### [4] - - -Wing 1990 - -##### [5] - - -Brookshear 2008 - -##### [6] - - -Boehm and Turner 2003 - -##### [7] - -**1. Modeling** - - -1.1. Modeling -Principles - - -c2s2, -c5s1, -c5s2 - - -c2s2 c5s0 - - -1.2. Properties -and Expression of -Models - - -c5s2, -c5s3 - - -c4s1.1p7, -c4s6p3, -c5s0p3 -1.3. Syntax, -Semantics, and -Pragmatics - - -c2s2.2.2 -p6 -c5s0 - - -1.4. Preconditions, -Postconditions, and -Invariants - - -c4s4 - - -c10s4p2, -c10s5 -p2p4 - -**2. Types of Models** - 2.1. Information - Modeling - c7s2.2 c8s1 - - -2.2. Behavioral -Modeling - - -c7s2.1, -c7s2.3, -c7s2.4 - - -c9s2 c5s4 - - -2.3. Structure -Modeling - - -c7s2.5, -c7s3.1, -c7s3.2 - - -c5s3 c4 - -**3. Analysis of Models** - 3.1. Analyzing for - Completeness - - -c4s1.1p7, -c4s6 -pp8–11 - - -3.2. Analyzing for -Consistency - - -c4s1.1p7, -c4s6 -pp8–11 - - -3.3. Analyzing for -Correctness -pp8–11 - - -3.4. Traceability -c4s7.1, -c4s7.2 -3.5. Interaction -Analysis -c10, c11 -c29s1.1, -c29s5 -c5 - - - -Software Engineering Models and Methods 9-11 - - -Budgen 2003 - -##### [1] - - -Mellor and Balcer 2002 - -##### [2] - - -Sommerville 2011 - -##### [3] - - -Page-Jones 1999 - -##### [4] - - -Wing 1990 - -##### [5] - - -Brookshear 2008 - -##### [6] - - -Boehm and Turner 2003 - -##### [7] - -**4. Software -Engineering Methods** - - -4.1. Heuristic -Methods - - -c13, c15, -c16 - - -c2s2.2, -c7s1, -c5s4.1 -4.2. Formal Methods c18 c27 pp8–24 -4.3. Prototyping -Methods -c12s2 c2s3.1 c7s3p5 - - -4.4. Agile Methods c3 c7s3p7 -c6, app. -A - -##### REFERENCES - -[1] D. Budgen, _Software Design_ , 2nd ed., Addison-Wesley, 2003. - [2] S.J. Mellor and M.J. Balcer, _Executable UML: A Foundation for Model-Driven -Architecture_ , 1st ed., Addison-Wesley, 2002. +Architecture_, 1st ed., Addison-Wesley, 2002. -[3] I. Sommerville, _Software Engineering_ , 9th ed., Addison-Wesley, 2011. +[3] I. Sommerville, _Software Engineering_, 9th ed., Addison-Wesley, 2011. -[4] M. Page-Jones, _Fundamentals of Object- Oriented Design in UML_ , 1st ed., +[4] M. Page-Jones, _Fundamentals of Object- Oriented Design in UML_, 1st ed., Addison- Wesley, 1999. -[5] J.M. Wing, “A Specifier’s Introduction to Formal Methods,” Computer , vol. +[5] J.M. Wing, “A Specifier’s Introduction to Formal Methods,” Computer, vol. 23, no. 9, 1990, pp. 8, 10–23. [6] J.G. Brookshear, Computer Science: An Overview , 10th ed., Addison-Wesley, 2008. [7] B. Boehm and R. Turner, Balancing Agility and Discipline: A Guide for the -Perplexed , Addison-Wesley, 2003. +Perplexed, Addison-Wesley, 2003.