Software Engineering Lecture 12 Software Lifecycle 1 Software

Software Engineering Lecture 12 - Software Lifecycle 1

Software Development Process 2

Lecture overview • • Documenting Architecture Implementing Coding Standards and Documentation (Testing) and Debugging Deployment and Mobility Maintenance Configuration management 3

Architecture Documentation • Even the best architecture will be useless if the people who need it – do not know what it is; – cannot understand it well enough to use, build, or modify it; – misunderstand it and apply it incorrectly. • All of the effort, analysis, hard work, and insightful design on the part of the architecture team will have been wasted. © Len Bass, Paul Clements, Rick Kazman, distributed under Creative Commons Attribution License

Purpose and Views • Purpose: – Education – Communication amongst stakeholders – System analysis and construction • Views – – Module view Component and Connectors (C&C) view Allocation view Quality view 5

Documenting Architecture • Architecture Description Languages – (WIKI) http: //en. wikipedia. org/wiki/Architecture_description_language – (Short overview) http: //www. mrtc. mdh. se/han/Fo. Plan/ass 2 -bjornander. pdf – (Component based design, the ACME architectural framework and the Rapide architecture description language) http: //hph 16. uwaterloo. ca/~bshihada/publications/adlweb. pdf • Human and machine interpretable… 6

Rapide Type Auto. Controls is interface Provides function speedometer return MPH; function Gas return Gallons; in action Steering_Wheel (A: Angle), in action Accelerator(P : Position), in action Brake(p : Pressure); out action Warning(S : Status); Behavior Speedometer > 55 ||> Accelerator(0) || Brake(High) || Warning(On); ; ……. . End Auto. Controls; 7

AO (Aspect Oriented) -ADL 8

UML as ADL • • Class diagrams Sequence diagrams Module diagrams Etc. 9

IMPLEMENTING ARCHITECTURE

The Mapping Problem • Architecture-based development provides a unique twist on the classic problem – It becomes, in large measure, a mapping activity Design Decisions Implementation Artifacts • Maintaining mapping means ensuring that our architectural intent is reflected in our constructed systems 11

How do you implement a class diagram? 12

How do you implement a sequence diagram? 13

How do you implement a statechart? 14

How do you implement a use-case diagram? 15

Common Element Mapping • Components and Connectors – Partitions of application computation and communication functionality – Modules, packages, libraries, classes, explicit components/connectors in middleware • Interfaces – Programming-language level interfaces (e. g. , APIs/function or method signatures) are common – State machines or protocols are harder to map 16

Common Element Mapping (cont’d) • Dynamic Properties (e. g. , behavior): – Usually translate to algorithms of some sort – Mapping strategy depends on how the behaviors are specified and what translations are available – Some behavioral specifications are more useful for generating analyses or testing plans 17

Common Element Mapping (cont’d) • Non-Functional Properties – Extremely difficult to do since non-functional properties are abstract and implementations are concrete – Achieved through a combination of humancentric strategies like inspections, reviews, focus groups, user studies, beta testing, and so on 18

One-Way vs. Round Trip Mapping • Architectures inevitably change after implementation begins – For maintenance purposes – Because of time pressures – Because of new information • Implementations can be a source of new information – We learn more about the feasibility of our designs when we implement – We also learn how to optimize them Design Decisions Implementation Artifacts 19

Documenting changes • It’s better to write a “Out of date” note on a part of the architecture, than not documenting changes at all 20

CODING STANDARDS AND DOCUMENTATION

Names 1 • Use concatenated words – e. g. , cylinder. Length (has a camel. Hump L) • Begin class names with capitals • Variable names begin lower case • Constants with capitals – as in MAX_NAME_LENGTH – use static final – -- but consider method instead Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Names 2 • Data members of classes with an underscore – as in _time. Of. Day – or equivalent – to distinguish them from other variables • since they are global to their object • Use get…, set…. , and is… for accessor method – as in get. Name(), set. Name(), is. Box() • latter returns boolean • additional getters and setters of collections – e. g. , insert. Into. Name(), remove. From. Name(). Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Names, ctd. • Consider preceding with standard letters or combinations of letters – e. g. , C…. . for classes • as in CCustomer etc. – useful when the importance of knowing the types of names exceeds the awkwardness of strange-looking names. – or place these type descriptors at the end • And/or distinguish between instance variables, local variables and parameters – _length, length and a. Length Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Documenting Methods 1 • what the method does • why it does so • what parameters it must be passed (use @param tag) • exceptions it throws (use @exception tag) • reason for choice of visibility • known bugs Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Documenting Methods 2 • test description, describing whether the method has been tested, and the location of its test script • history of changes if you are not using a version management system • example of how the method works • pre- and post-conditions • special documentation on threaded and synchronized methods Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Attributes • Description -- what it's used for • All applicable invariants – quantitative facts about the attribute, – such as "1 < _age < 130" – or " 36 < _length * _width < 193". See www. ambysoft. com

Initializing Attributes should be always be initialized, think of private float _balance = 0; Attribute may be an object of another class, as in private Customer _customer; -- Traditionally done using the constructor, as in private Customer _customer = new Customer( "Edward", "Jones" ); Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

One Solution to Object Initialization Use initialization when the value is first accessed. Supply My. Class with static get. Default. My. Class(). Attributes are declared without initialization, then assigned values the first time they are accessed. In class Customer: Account Customer …. public static Customer get. Default. Customer() // … reasons these values are chosen for the default { return new Customer ( "John", "Doe", 0, 1000, -2000 ); }

(TESTING) AND DEBUGGING 30

A Strategy for Testing Conventional Software Na Br rro oa w de to rs co p e System Testing Validation Testing Integration Testing Unit Testing Ab co str nc ac re t to te Code Design Requirements System Engineering 31

Levels of Testing for Conventional Software • Unit testing – Concentrates on each component/function of the software as implemented in the source code • Integration testing – Focuses on the design and construction of the software architecture • Validation testing – Requirements are validated against the constructed software • System testing – The software and other system elements are tested as a whole 32

Ensuring a Successful Software Test Strategy • Specify product requirements in a quantifiable manner • State testing objectives explicitly in measurable terms • Understand the user of the software (through use cases) and develop a profile for each user category • Develop a testing plan that emphasizes rapid cycle testing to get quick feedback 33

Ensuring a Successful Software Test Strategy cont’d • Build robust software that is designed to test itself and can diagnose certain kinds of errors • Conduct formal technical reviews to assess the test strategy and test cases themselves • Develop a continuous improvement approach for the testing process through the gathering of metrics 34

Debugging Process • It is still very much an art rather than a science • The debugging process begins with the execution of a test case • Results are assessed and the difference between expected and actual performance is encountered • This difference is a symptom of an underlying cause that lies hidden • The debugging process attempts to match symptom with cause, thereby leading to error correction 35

Why is Debugging so Difficult? • The symptom and the cause may be geographically remote • The symptom may disappear (temporarily) when another error is corrected • The symptom may actually be caused by nonerrors (e. g. , round-off accuracies) • The symptom may be caused by human error that is not easily traced (continued on next slide) 36

Why is Debugging so Difficult? (continued) • The symptom may be a result of timing problems, rather than processing problems • It may be difficult to accurately reproduce input conditions, such as asynchronous real-time information • The symptom may be intermittent such as in embedded systems involving both hardware and software • The symptom may be due to causes that are distributed across a number of tasks running on different processes 37

Question • How do you debug software? 38

Debugging Strategies • Objective of debugging is to find and correct the cause of a software error • Bugs are found by a combination of systematic evaluation, intuition, and luck • Debugging methods and tools are not a substitute for careful evaluation based on a complete design model and clear source code • There are three main debugging strategies – Brute force – Backtracking – Cause elimination 39

Strategy #1: Brute Force • Most commonly used (but not necessarily the best) • Used when all else fails • Involves the use of memory dumps, run-time traces, and output statements • Helped by debugging tools – – Breakpoints Step-by-step tracing Variable values / condition checking Watches 40

Strategy #2: Backtracking • Can be used successfully in small programs • The method starts at the location where a symptom has been uncovered • The source code is then traced backward (manually) until the location of the cause is found • In large programs, the number of potential backward paths may become unmanageably large 41

Strategy #3: Cause Elimination • Involves the use of induction or deduction – Induction (specific to general): Prove that a specific starting value is true; then prove the general case is true – Deduction (general to specific): Show that a specific conclusion follows from a set of general premises 42

Debugging - Induction • Locate, Organize, Device a hypothesis, Prove the hypothesis 43

Debugging - Deduction • Enumerate the possible causes or hypotheses, Use the data to eliminate possible causes, Refine, Prove… 44

Three Questions to ask Before Correcting the Error • Is the cause of the bug reproduced in another part of the program? – Similar errors may be occurring in other parts of the program • What next bug might be introduced by the fix that I’m about to make? – The source code (and even the design) should be studied to assess the coupling of logic and data structures related to the fix • What could we have done to prevent this bug in the first place? – This is the first step toward software quality assurance – By correcting the process as well as the product, the bug will be removed from the current program and may be eliminated from all future programs 45

A Summary of Key Issues in Programming • Implementation standards • Documentation techniques • Debugging – Programmer must systematically check a program’s logic to determine where an error occurs – Tools to use while debugging: • Watches • Breakpoints • print statements • Dump functions

Questions?