Week 6 [Fri, Feb 16th] - Topics

Sequence diagrams model the interactions between various entities in a system, in a specific scenario. Modelling such scenarios is useful, for example, to verify the design of the internal interactions is able to provide the expected outcomes.

Contents related to UML diagrams in the panels given below belong to a different chapter (i.e., the chapter dedicated to UML); they have been embedded here for convenience.

The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. Architecture is concerned with the public side of interfaces; private details of elements—details having to do solely with internal implementation—are not architectural. _{-- Software Architecture in Practice (2nd edition), Bass, Clements, and Kazman}

The software architecture shows the overall organization of the system and can be viewed as a very high-level design. It usually consists of a set of interacting components that fit together to achieve the required functionality. It should be a simple and technically viable structure that is well-understood and agreed-upon by everyone in the development team, and it forms the basis for the implementation.

A possible architecture for a Minesweeper game:

Main components:

• GUI: Graphical user interface
• TextUi: Textual user interface
• ATD: An automated test driver used for testing the game logic
• Logic: Computation and logic of the game
• Store: Storage and retrieval of game data (high scores etc.)

The architecture is typically designed by the software architect, who provides the technical vision of the system and makes high-level (i.e. architecture-level) technical decisions about the project.

Architecture diagrams are free-form diagrams. There is no universally adopted standard notation for architecture diagrams. Any symbols that reasonably describe the architecture may be used.

In a smaller system, the design of the entire system can be shown in one place.

This class diagram of se-edu/addressbook-level2 depicts the design of the entire software.

The design of bigger systems needs to be done/shown at multiple levels.

This architecture diagram of se-edu/addressbook-level3 depicts the high-level design of the software.

Here are examples of lower level designs of some components of the same software:

UI

---

Logic

---

Storage

---

Debugging is the process of discovering defects in the program. Here are some approaches to debugging:

• Bad -- By inserting temporary print statements: This is an ad-hoc approach in which print statements are inserted in the program to print information relevant to debugging, such as variable values. e.g. Exiting process() method, x is 5.347. This approach is not recommended due to these reasons:
  • Incurs extra effort when inserting and removing the print statements.
  • These extraneous program modifications increase the risk of introducing errors into the program.
  • These print statements, if not removed promptly after the debugging, may even appear unexpectedly in the production version.
• Bad -- By manually tracing through the code: Otherwise known as ‘eye-balling’, this approach doesn't have the cons of the previous approach, but it too is not recommended (other than as a 'quick try') due to these reasons:
  • It is a difficult, time consuming, and error-prone technique.
  • If you didn't spot the error while writing the code, you might not spot the error when reading the code either.
• Good -- Using a debugger: A debugger tool allows you to pause the execution, then step through the code one statement at a time while examining the internal state if necessary. Most IDEs come with an inbuilt debugger. This is the recommended approach for debugging.

• IntelliJ IDEA Documentation: Debugging Basics - Can be used as a reference document when you want to recall how to use a debugging feature.

Some useful navigation shortcuts:

1. Quickly locate a file by name.
2. Go to the definition of a method from where it is used.
3. Go back to the previous location.
4. View the documentation of a method from where the method is being used, without navigating to the method itself.
5. Find where a method/field is being used.

Logging is the deliberate recording of certain information during a program execution for future reference. Logs are typically written to a log file but it is also possible to log information in other ways e.g. into a database or a remote server.

Logging can be useful for troubleshooting problems. A good logging system records some system information regularly. When bad things happen to a system e.g. an unanticipated failure, their associated log files may provide indications of what went wrong and actions can then be taken to prevent it from happening again.

Most programming environments come with logging systems that allow sophisticated forms of logging. They have features such as the ability to enable and disable logging easily or to change the logging .

import java.util.logging.*;

    

    


    
    
    

      


    
    

private static Logger logger = Logger.getLogger("Foo");

    

    


    
    
    

      


    
    

// log a message at INFO level
logger.log(Level.INFO, "going to start processing");
// ...
processInput();
if (error) {
    // log a message at WARNING level
    logger.log(Level.WARNING, "processing error", ex);
}
// ...
logger.log(Level.INFO, "end of processing");