Rights n n This presentation is solely for

CS 5704 Software Engineering Class 3 v. 6 n n n n n Introduction

Introduction Do readings before do project work n Near end of class will discuss

Scheme of Early Part of Course Identify needs 11/9/2020 Understand situation and alternative solutions

Review of Homework Liked the listing of unanswered questions and activities to investigate/ mitigate

Framework for Software Engineering Representing, Engineering, Enacting, and Changing Enterprises (including Projects) or Systems,

Overview n n n n Software Engineering Combines Several Fields Projects Involve Many Entities

Software Engineering’s Location Management Systems Engineering Software Engineering Computer Science Organizational Studies 11/9/2020 ©

Software Engineer’s Location Application Area Systems Engineering Specialties 11/9/2020 Management Software Engineer Organizational Studies

Project Entity. Relationship Goals Strive to meet Impact Evaluated against Output Guide Process Activities

Examples n Human oriented • Need: Stay fed • Goal: Have meal to eat

Project-Related Entities Inheritance Hierarchy n Foundation 11/9/2020 • • • Goals Activities Products •

Activities n n Decide Produce Most “Lifecycle” engineering and many management activities go here

Products n Tangibles • Externally Committed – Deliverable – Non-deliverable • Internally Committed –

Means n Means required by activity • Roles (to be performed) • Aids (to

Engineer and Do Plan Enact Generic and Alternative Process Descriptions Plan: Process Description for

Processes n n n Futures Present (being enacted) [Just the change between Future and

Doing activities (manual or automated) is a central issue n In the next several

Doing - 1 Existing Potentially (Re)Usable Items (Possibly Generic & Partial) Tools Other Stakeholders

Doing - 2 Existing Potentially (Re)Usable Items (Possibly Generic & Partial) Tools Interaction Mechanisms

Supplier-Customer Chain Items Supplier Items Tool Supplier 11/9/2020 Results Process Supplier © 1997 -2001

Supplier-Customer 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 22

Software Engineering Picture Representation of Reusable Software Processes Representation of Reusable Software Representation of

Summary Project-related entities include goals, process descriptions, activities, products, means, and risks n Actor

Blackbox Can see only surface interface, not interior Interfacing dependably with a “blackbox” requires

Systems and Subsystems 1 2 3 11/9/2020 4 5 Overlap © 1997 -2001 Samuel

World 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 27

Software Is in Larger Contexts n Software operates in a system which is embedded

Agents/Actors Sensors Informational Agent Informational agent • Receives input from sensors Effectors • Provides

Four Variable Model Sensors Input Real World 11/9/2020 Computation Effectors Output Hardware Software ©

Relations Sensors Real E/S World Hardware Input I/O S/E Effectors 11/9/2020 S/I O/E Computation

Which Relation? Invisible Visible 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer.

Documentation Hw/Sw Statement of Situation Interface Sensors Real E/S World Needs Fulfilled S/E Effectors

How Discuss Each of these relations describe dynamic behavior n Going to use I/O

Remarks on Specifying Traditionally Say about Specifications n Continuity of Representations n Step-by-Step Refinement

Remarks on Specifying n Forget traditional contrast between specifications and code and think of

Continuity of Representations n n Use series of representations from abstract specification to more

Increasing Constraints on Computation Needs Code Design External Behavior Essential Requirements 11/9/2020 © 1997

Step-by-Step Refinement n n n Initial representation of software system generally abstract having only

Step-by-Step Refine Essential Requirements to Code Needs Code Design External Behavior Essential Requirements More

Specification Still Can Be Hard n To Specify Must Have 11/9/2020 • Functionality: Understanding

Summary Step from abstract and essential to concrete and executable n Refine so consistent

Fundamentals of Computation n. A Computational Unit as Black-Box n A Computational Unit in

Black-Box External Behavior When does it execute? What is the result? Computational Unit What

Static Analysis of Black-Box External Behavior When might it execute? What might result? Computational

Static Analysis of Black-Box External Behavior What might result? Might nothing result? When might

When Executes n Occurrence (or potential occurrence) of execution of a computational unit requires

Internal Execute Prevent/Allow When environment allows execution, then guard allows/prevents execution. When execution allowed,

Internal Prevent/Allow of Execution When execution allowed, environment Results constrained to what might allows

Issues about Before and After Postcondition Precondition Computation Result Termination 11/9/2020 © 1997 -2001

Characterizing Computation After Before Domain 11/9/2020 Relationship Range © 1997 -2001 Samuel T. Redwine,

Refinement Precondition = Stand here 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s.

Operations n Consider constraints and timing • Before/input values • After/output values Part of

What Need in Representations n Static representations that allow • • • Understanding of

Predict Behavior Have representations of what it should and should not do at interfaces

Structured Arrangements n Structures should allow calculation • When might execute • What might

Structures for Composing Units Simple sequence n Invocation (same thread) n Alternatives (if. .

Pre/Post versus Forever So far we have modeled computation as having a start and

Representing What n Kinds of things or entities n Aspects n About the representations

Artifact/Product Quality Criteria ity l i b a t s e t / y

Representational Relationships n Incrementally different • Derived • Inheritance n Across bases • Translation

Representation and Represented n Too a fair extent, the same kinds of representations are

Engineering Design Succeeds in Real World n Can be built n Problem solving n

Designer Formal Methods Actions n Represent n n Compose Abstract Refine Compare Prove n

Summary n Software Engineer needs • A keen understanding of the environment, stakeholders, and

Break and Meetings 10 Minute Left 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr.

Requirements and Architecture Hope understand specification better after first half n Architecture contains high-level

Purposes of Architecture Provide basis for detailed design, etc. n Allow intellectual mastery of

Analyze Requirements and Specify n n Social issues can dominate Separate but relate descriptions

Customers and Users n Work closely with key customers • • • n n

Requirements n n Principles system follows: rules or schemes to be followed throughout Separately

Choosing Notation and Abstraction deals with some things but not others n Designer chooses

Dataflow Source Dataflow Process Storage Sink 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr.

Psuedocode Use only three structured programming Structures n Some names may have no implementation

Entity-Relationship For Real World or Data Car Ownership Person Relationship can be one-to-one, many-to-many

Object-Oriented Inheritance n Polymorphism n Method/Operation n Encapsulation n Has no state or does

Finite State Machines Initialization n Made up of • States • Transitions X –

Design - 1 n n Design for quality requirements/criteria Intellectual manageability • Architecture •

Design - 2 n Verifiability • • • n n Traceability Rigor Tractability Stimulate-ability

Quality Often Architectural n n n Integration and dependability issues often must involve early,

A Simple Model Context Overall Process Construct Activity Plan Establish Requirements Do Evaluate Improve

Fault Tolerance Design Redundancy Process 1 Process 2 Vote Process 3 Test Process 2

Design Summary n n n Quality planned Quality of designers Design process - feedback

Code Rigorous specifications n Use Style Guide n Refinement/proofing n Review before test n

Prototype n Establish • • Goals/objectives Questions to be answered Metrics to be used

Reviews When Might Review n Peer Reviews n 11/9/2020 © 1997 -2001 Samuel T.

Activity-Artifact Evaluations Potential Time for Artifact Evaluation Potentially also Process Evaluations Intermediate Activity Evaluate

Peer Reviews Purposes n Process n Varieties n 11/9/2020 © 1997 -2001 Samuel T.

Purposes of Peer Reviews Finding faults or opportunities for improvement n Verification n Validation

Peer Review Process n Organization • Policy and procedures • Project plans – Occurrence

Variety of Peer Reviews Traditional reviews n Inspections n Distributed processes n May or

Summary Stakeholders and real world help determine requirements and expected quality n One of

Many Factors Effect Quality Requirements n Construction process n Means used in construction n

Discussion n So far in course • What was good? • What could be

Deliverables Due Next Class n n n Needs list Draft Features list Draft List

Conclusion Similar models can describe informational behaviors of software process engineer, software engineer, computation,

Slides: 97

Download presentation

Rights n n This presentation is solely for use in summer 2001 CS 5704 at Virginia Tech. The sole right granted to each summer 2001 CS 5704 student is to print a single paper copy for use in this class. After producing a paper copy, students must remove this presentation from their computers and storage media. Students may not transfer any copy of this presentation to any third party. Each chart is copyrighted and must not be copied, reproduced, or otherwise used in any form without written permission of its copyright holder, Samuel T. Redwine, Jr. who reserves all rights. 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 1

CS 5704 Software Engineering Class 3 v. 6 n n n n n Introduction (7: 00 -7: 05) Review of Homework (7: 05 -7: 15) Framework for Software Engineering (7: 158: 25) Break (8: 25 -8: 35) Requirements and Architecture (8: 35 -9: 05) Reviews (9: 05 -9: 20) Questions about Third-term Exam (9: 20 -30) Discussion of how course has gone so far (9: 30 -9: 45) Conclusion (9: 45) 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 2

Scheme of Early Part of Course Identify needs 11/9/2020 Understand situation and alternative solutions Choose and justify to client a general alternative Detail and reach agreement with client on alternative’s behavior, structure, and development plan © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 4

Review of Homework Liked the listing of unanswered questions and activities to investigate/ mitigate risks n In doing needs and requirements, one thought per entry n From what you learned from the readings, what did you use in doing the project work? n 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 5

Framework for Software Engineering Representing, Engineering, Enacting, and Changing Enterprises (including Projects) or Systems, Composed of Arrangements of People, Hardware, Software, and Processes in Environments 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org© 6

Overview n n n n Software Engineering Combines Several Fields Projects Involve Many Entities Doing The Purposes of Models Representations and Conceptual Bases Representing Computation and Organizations Commonalties 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 7

Software Engineer’s Location Application Area Systems Engineering Specialties 11/9/2020 Management Software Engineer Organizational Studies Interpersonal Relations Computer Science Professionalism © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 9

Project Entity. Relationship Goals Strive to meet Impact Evaluated against Output Guide Process Activities Products Descriptions Produce Input to “Actuals” Mitigate Supply & Supply Consume To execute impact require & use Impact performance Risks and Opportunities of 11/9/2020 Means Contribute to Supply Contexts © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 10

Examples n Human oriented • Need: Stay fed • Goal: Have meal to eat • Activity: Cook • Products: Ingredients, Plate & Meal • Means: Person(s), Utensils, Stove, Electricity • Processes: Recipes 11/9/2020 n Computer oriented • Need: Satisfy user • Goal: Meet postcondition • Activity: Run program • Means: Computing equipment & electricity • Process: Program © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 11

Project-Related Entities Inheritance Hierarchy n Foundation 11/9/2020 • • • Goals Activities Products • • • Means Contexts Processes (To be, are, have been) Risks and Opportunities Organizations – Tangibles – Intangibles © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 12

Activities n n Decide Produce Most “Lifecycle” engineering and many management activities go here • Produce Product • Produce Service n n n Take Action Measure Evaluate Communicate Document (for the record) 11/9/2020 n n n n CM QA Improve Process Improve people Train Purchase Overhead Milestone © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 13

Products n Tangibles • Externally Committed – Deliverable – Non-deliverable • Internally Committed – Deliverable – Non-deliverable n Intangibles • • Knowledge Skill Expectations Intentions • Status Reports • Messages 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 14

Means n Means required by activity • Roles (to be performed) • Aids (to be used but reusable afterwards) • Consumables (to be used up) Units of measure of amounts required and used also of interest 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. n Fulfilling required means • Funds • Resources – Organizations • Anonymous • Identified – Persons • Anonymous • Identified – Automation • Software items • Hardware items – Products – Activities s. redwine@computer. org 15

Engineer and Do Plan Enact Generic and Alternative Process Descriptions Plan: Process Description for Future Process Instance History: Plan & Actual; Process Description of Past Process Instance Select, Instantiate, Modify, Compose 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 16

Processes n n n Futures Present (being enacted) [Just the change between Future and History? ] Histories 11/9/2020 n Timelines • Baselines • Variances n Some Attributes • • • Cost Schedule Quality Predictability Resources Results © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 17

Doing activities (manual or automated) is a central issue n In the next several charts, ignoring consumables -- for example, electricity and paper n Introduce the concept of “actor” n 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 18

Doing - 1 Existing Potentially (Re)Usable Items (Possibly Generic & Partial) Tools Other Stakeholders Kinds of means Doer/Actor/Agent Results: State and Items Tool, Item, & Process User Process for Doing Work 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 19

Doing - 2 Existing Potentially (Re)Usable Items (Possibly Generic & Partial) Tools Interaction Mechanisms Other Stakeholders Results: State and Items Doers/Actors/Agents Tool, Item, Interaction Mechanism, & Process Users Process for Doing Work 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 20

Software Engineering Picture Representation of Reusable Software Processes Representation of Reusable Software Representation of Software Representation Software of Software Project Process Engineer Process Enacting Project Engineer Description: Plans & Actuals 11/9/2020 Other Stakeholders Executing Instance of Software Operational Users System Procedures © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 23

Summary Project-related entities include goals, process descriptions, activities, products, means, and risks n Actor does its process using available resources and tools in a larger environment with suppliers, customers, and other stakeholders n 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 24

Blackbox Can see only surface interface, not interior Interfacing dependably with a “blackbox” requires having not only a static representation of its interface but a representation that predicts its dynamic behavior. 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 25

Software Is in Larger Contexts n Software operates in a system which is embedded in larger systems Enterprise Hw Procedures Sw People 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 28

Agents/Actors Sensors Informational Agent Informational agent • Receives input from sensors Effectors • Provides output to effectors Agents may have internal state. 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 29

Documentation Hw/Sw Statement of Situation Interface Sensors Real E/S World Needs Fulfilled S/E Effectors Hardware 11/9/2020 S/I Input System Requirements O/E I/O Computation Output Software Requirements Hw/Sw Interface Software © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 33

How Discuss Each of these relations describe dynamic behavior n Going to use I/O or Computational Unit as example to investigate them all n First discuss gradations of specification then characterizing a computational unit n 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 34

Remarks on Specifying Traditionally Say about Specifications n Continuity of Representations n Step-by-Step Refinement n Engineering Software Behavior n Formal Methods Aid Engineering n Specification Still Can Be Hard n Summary of Remarks on Specifying n 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 35

Remarks on Specifying n Forget traditional contrast between specifications and code and think of • Continuity of representations • Gradual step-by-step refinement Informal and formal methods aid the engineering of software behavior n Specification can be hard because need rich understanding of complex world n 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 36

Continuity of Representations n n Use series of representations from abstract specification to more concrete or executable No clear boundary between non-executable and executable representations All do the same thing, place constraints on software behavior Need to think of all these representations as the same kind of thing 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 37

Step-by-Step Refinement n n n Initial representation of software system generally abstract having only essential constraints As refine representation generally place tighter (stronger) constraints on resulting behavior If can show each refinement step results in constraints consistent with prior representation then end result consistent 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 39

Step-by-Step Refine Essential Requirements to Code Needs Code Design External Behavior Essential Requirements More about legitimate refinements later 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 40

Specification Still Can Be Hard n To Specify Must Have 11/9/2020 • Functionality: Understanding and prediction of environment/task • Reliability: Input distribution • Evolvability: Probabilities of kinds of future changes, their sequence, likelihood of occurring together, and constraints on doing • Safety: Hazards and accidents • Efficiency: Operational environment and nature of problem i. e. O (? ) • Security: Properties and threat characteristics • Probable Correctness: Way to measure © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 41

Summary Step from abstract and essential to concrete and executable n Refine so consistent with constraints n Specification is hard mainly for nontechnical reasons n 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 42

Fundamentals of Computation n. A Computational Unit as Black-Box n A Computational Unit in Some Environmental Scheme n Preconditions, Post-conditions, and Refinement n Composition of Multiple Units in Structured Arrangements 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 43

Black-Box External Behavior When does it execute? What is the result? Computational Unit What resources are used? 11/9/2020 Will result come out? What is duration? © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 44

Static Analysis of Black-Box External Behavior When might it execute? What might result? Computational Unit Might a result never come out? 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 45

Static Analysis of Black-Box External Behavior What might result? Might nothing result? When might it execute? One needs to characterize and calculate 11/9/2020 Computational Unit One needs to characterize and calculate © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 46

Static Analysis of Black-Box External Behavior What might result? Might nothing result? When might it execute? One needs to characterize and calculate Computational Unit One needs to characterize and calculate Formal Methods use mathematical representations and reasoning to accomplish these. Informal can aid. 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 47

When Executes n Occurrence (or potential occurrence) of execution of a computational unit requires two things to be true • Whatever scheme exists in the unit’s environment must allow unit to execute • Whatever self-contained scheme the unit has to allow/prevent its own execution must allow unit to execute 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 48

Internal Execute Prevent/Allow When environment allows execution, then guard allows/prevents execution. When execution allowed, what might result? Guard Computation 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 49

Internal Prevent/Allow of Execution When execution allowed, environment Results constrained to what might allows execution, only those results from result? then guard when allowed to execute allows/prevents execution. Guard Computation 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 50

Operations n Consider constraints and timing • Before/input values • After/output values Part of an operation’s constraints relate before/input and after/output values n Operation’s “Precondition and postcondition” n 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 54

What Need in Representations n Static representations that allow • • • Understanding of structure Specification of behavior Prediction of dynamic behavior – Internal – At interface 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 55

Predict Behavior Have representations of what it should and should not do at interfaces n Show that interior is such that it has n • Liveness properties: Will make progress toward what it should do • Safety properties: Will not ever do bad things • Timing is ok • Resource usage is acceptable 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 56

Structured Arrangements n Structures should allow calculation • When might execute • What might happen – Results – No results (termination is a result) 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 58

Structures for Composing Units Simple sequence n Invocation (same thread) n Alternatives (if. . fi) n G C Iteration (do. . od) G C n Recursion (not covered) n Concurrency (limited coverage) n 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 59

Pre/Post versus Forever So far we have modeled computation as having a start and a stop n Can also model as having a start but running forever n The forever model particularly good for concurrent systems and calculating their liveness and safety properties n 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 60

Representing What n Kinds of things or entities n Aspects n About the representations themselves • Existing • Doing/Changing 11/9/2020 • • Functionality - Non-Functionality Automation - Non-Automated Internals - Externals - Relationships Perspectives • • • Meaning Reasoning about Relationships among differing representations of/about same or related things © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 63

Artifact/Product Quality Criteria ity l i b a t s e t / y rifiabilit e V ecurity S cy a r u y c t c e f A a S F ty i l B i b T a M s / u y t i e l i R e c Reliab n a ty i l m i r b o f a n d o n a C t Unders Standards lerance ity l i b a v i v r o u T S Fault y c n y t e i i l i c i b f f a t e / p e a c d n A s s Performa e n ity c i l lete p p m i m s o / y C t lexi y t p i l i m b o a l i C a v A ility b a s U Portability d i l a V ility b a t n e y t i l m i e b l a p n i m I a t ain tion M a r g e t n i f r owe P Level o e fit p e o n c e S b / / t y t s i l o C s Genera s e n e v Competiti 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 64

Representational Relationships n Incrementally different • Derived • Inheritance n Across bases • Translation • Transformation n Interface • Two-way encapsulation: • Requirements and guarantees (Assumptions) • Implementation – Refinement • Abstract-Concrete • Less executable. More executable • Optimization 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 65

Representation and Represented n Too a fair extent, the same kinds of representations are used to represent the informational aspects of • • 11/9/2020 The user organization process The software engineering process Hardware/Software system Computation © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 66

Summary n Software Engineer needs • A keen understanding of the environment, stakeholders, and future of the software • Knowledge of the known alternatives • Skill in software engineering methods • Creativity and problem solving skills • Interpersonal and conflict resolution skills • Comfort with a high rate of change and learning • Professionalism especially integrity and awareness of limitations • A well-developed aesthetic sense 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 69

Requirements and Architecture Hope understand specification better after first half n Architecture contains high-level and key structure and relationships, and constraints and stereotypes for all structure and relationships n 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 71

Purposes of Architecture Provide basis for detailed design, etc. n Allow intellectual mastery of full scope of system n Reflect most important concerns and properties n Typically, provide for or facilitate: reuse, evolution, integration, and dependability n 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 72

Analyze Requirements and Specify n n Social issues can dominate Separate but relate descriptions of • • • n n Problem or opportunity (need) Essential requirements of solutions (S/E & I/O) Solution Constructing(ed) Process is inevitably intertwined with design Tractability Validability Verifiability including testability 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 73

Customers and Users n Work closely with key customers • • • n n Involve all stakeholders as appropriate In internal development • • • n Advanced Typical Richest market Permanent liaisons with departments Involve users on development team Conflict resolution can be a key skill Consider participative development 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 74

Requirements n n Principles system follows: rules or schemes to be followed throughout Separately and uniquely recorded and identified -- current plus likely future changes Hierarchical span and modularity Group together • • n Cohesive functionality Separation of concerns Virtual machines Likely to change together Fit to situation (e. g. O-O, dataflow, and matrices all are best fits for different areas) 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 75

Choosing Notation and Abstraction deals with some things but not others n Designer chooses to describe some aspects but not others n Many levels of granularity n • From single statement • To entire system 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 79

Object-Oriented Inheritance n Polymorphism n Method/Operation n Encapsulation n Has no state or does all interaction with its state n 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 83

Finite State Machines Initialization n Made up of • States • Transitions X – Usually Guarded – Sometimes modeled with side effects n n n Other representations often mapped to FSM for reachability analysis Some FSM allow transitions to same state A Safety Spec may forbid state(s) 11/9/2020 A K B Safety Spec N C M V © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org Transition to same state R 84

Design - 1 n n Design for quality requirements/criteria Intellectual manageability • Architecture • Understandability • Analyzability n n Design by refinement Pre- and postconditions 11/9/2020 n Multiple • • n Alternatives Cycles Perspectives Stakeholders involved Use engineering principles © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 85

Design - 2 n Verifiability • • • n n Traceability Rigor Tractability Stimulate-ability Controllability Observability: interfaces & interior Assertions Built-in Measurement and Problem Reporting Built-in Test Fault Tolerance 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 86

Quality Often Architectural n n n Integration and dependability issues often must involve early, pervasive design decisions Integration, safety, security, fault tolerance, survivability, verifiability and analyzability can seldom if ever be achieved as afterthoughts or add-ons Adaptability, reusability, and easy evolution and upgrades often architectural 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 87

A Simple Model Context Overall Process Construct Activity Plan Establish Requirements Do Evaluate Improve Execute with Assessment & Fault Tolerance Customers Legal Means People Tools Infrastructure Reuse 11/9/2020 Users Competitors Labor Pool Investors Suppliers Standards Guidelines Available Suppliers Organization © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 88

Fault Tolerance Design Redundancy Process 1 Process 2 Vote Process 3 Test Process 2 Test Recovery Block N-Version Data Redundancy 11/9/2020 Process 1 Process 3 Compare © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 89

Design Summary n n n Quality planned Quality of designers Design process - feedback to requirements, multiple alternatives Architecture Design methods and representations Features included for • Verifiability • Built-in – Measurement – Problem reporting – Fault tolerance 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 90

Prototype n Establish • • Goals/objectives Questions to be answered Metrics to be used to answer questions Prototyping approach Develop prototype n Evaluate prototype n Report on prototype n Place (re)usable results under CM Most common problem is throwaway prototype not sticking to just answering questions. 2 nd is inexcusable engineering. n 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 92

Activity-Artifact Evaluations Potential Time for Artifact Evaluation Potentially also Process Evaluations Intermediate Activity Evaluate Input 11/9/2020 Evaluate Activity Readiness Proposed Final © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 94

Purposes of Peer Reviews Finding faults or opportunities for improvement n Verification n Validation n Professional development n 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 96

Peer Review Process n Organization • Policy and procedures • Project plans – Occurrence – Participants • Moderator training • Staff training • Process auditing & enforcement 11/9/2020 n Each review • • • Plan Prepare for review Review Follow-up Report Repeat as needed © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 97

Variety of Peer Reviews Traditional reviews n Inspections n Distributed processes n May or may not have n • • • 11/9/2020 Meeting Moderator Official quality report Quality “grade” Formal methods basis (e. g. Cleanroom) Automated support © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 98

Summary Stakeholders and real world help determine requirements and expected quality n One of many ways to evaluate quality is a peer review n 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 99

Many Factors Effect Quality Requirements n Construction process n Means used in construction n Operational fault tolerance and support n Expectations and perceptions n 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 100

Deliverables Due Next Class n n n Needs list Draft Features list Draft List of Components n Traceability between n Optional: Storyboards, Prototype, E-R diagram • For each component list of tasks to produce it 11/9/2020 • Needs and features • Features and components © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 102

Conclusion Similar models can describe informational behaviors of software process engineer, software engineer, computation, and user n Four Variable Model helps clarify relationships n Use the notation that is best for you n Redwine’s Software Engineering Guide Service A Fall Learning Experience 11/9/2020 © 1997 -2001 Samuel T. Redwine, Jr. s. redwine@computer. org 103