Software Engineering and Architecture

• Redocumentation
  • pretty printers
  • diagram generators
  • cross-refernce listing generators
• Design recovery
  • software metrics
  • browsers, vusualization tools
  • static analyzers
  • dynamic (trace) analyzers

• Unbundling
  • split a monolithic system into parts that can be separately marketed
• Improve performance
  • "first do it, then do it right, then do it fast" - experience shows this is the right sequence!
• Port to other Platform
  • the architecture must distinguish the platform dpendent modules
• Design extraction
  • to improve maintainability, portabiity, etc.
• Exploitation of new technology
  • i.e. new language features, standards, libraries, etc.

Before you reengineer some code, you have to reverse engineer it to understand the code

Segging Direction:

• Typical reverse or reengineering project wil be burdened with a lot of interests that pull in different directions
• You will detext many problems with the legacy software, and it will be hard to set priorities
• Communication in such projects can be complicated by either the presence or absence of the original development team

You should Agree on Maxims in order to establish a common understanding within the team of what is at stake and how to achieve it.

To help you focus on the right problems and the critical decisions, it is wise to tackle the Most Valuable First.

First contact

All the patterns in the First Contact cluster can be applied to the very early stages of a reverse engineering project:  You are facing a system that is completely new for you, and within a few days you must determine whether something can be done with it and present a plan how to proceed.

• Legacy systems are large and complex. Consequently, split the system in to manageable pieces, where a manageable piece in one you can handle with a single reengineering team.
• Time is scarce. It is tempting to start an activity that will keep you busy for a while instead of addressing the root of the problem. Therefore, defer all time-comsuming activities until later and use the first days of the project to assess the feasibility of the project's goals.
• First impressions are dangerous. There is no way to avoid that risk during your first contact with a system, however you can minimize its impact if you always doulche-check your sources.
• People have different agendas. In order to make the project a success, you must keeep convincing the faithful, gain credit with the fence sitters and be wary of the skeptics.

Wastin time is the largest risk when you have your first contact with a system, therefore these patterns should be applied during a short time span, say one week. After this week you should grasp the main issues and based on that knowledge plan further activities, or - when necessary - cancel the project.

Learn about the historical and political context of your project through discussions with the people maintaining the system.

• Easiest/hardest bug to fix in recent moths?
• How are change requests made and evaluated?
• How did the development/maintenance team evolve during the project?
• How good is the code? The documentation?
• Why was the reengineering project started? What do you hope to gain?

Assess the state of a software system by means of a brief, but intensive code review.

Obtain an initial feeling for the appreciated functionality of a software system by seeing a demo and interviewing the person giving the demo.

Hints:

• An end-user should tell you how the system looks like from the ouside and explain some detailed usage scenarios based on the daily working practices
• A manager should inform you how the system fits within the rest of the business domain
• A person from the sales department ought to compare your software system with competing systems
• A person from the help desk should demonstrate you which features cause most of the problems
• A system administrator should show you all that is happening behind the scenes of te software system. Ask for past horror stories to assess the reliability of the system
• A developer may demonstrate you some of the subsystems. Ask how this subsystem communicates with the other subsystems and why (and who!) it was designged thtat way. Use the opportunity to get insight in the architecture of the system and the trade-offs that influenced the design.

• Speculate about design
  • Develop hypotheses and check them
• Analyze the persistent data
  • Analyze the database schema and filter out which strucutres represent valuable data. Derive a class diagram representing those entities to document that knowledge for the rest of the team
• Study the exceptional cases
  • Measure software entities and study the anomalous ones

• Tie Code and Questions
  • Keep the questions and answers concerning your reengineering activities synchronized with the code by storing them directly in the source files
• Refactor to understand
  • Iteratively refactor a part of a software system in order to validate and reflect your understanding of how it works
• Step through the execution
  • Understand how objects in the system collaborate by stepping through examples in a debugger
• Look for the contracts
  • infer the proper use of a class interface by studying the way clients currently use it
• Write tests to understand

Test driven Development

• The developer writes test code before writing functional code
• The developer writes test code that initaially breaks at compile time
• The developer writes test code that initially breaks at execution time
• The developer writes "just enough" functional code to pass the tests
• New test cases are added iteratively

Using TDD has many benefits but the most relevant is that it directs the programmer to think about the design of code from its intended use, rather than from its implementation.

TSS also tends to produce simpler code becaus it focuses on immediate requirements rather than future-proofing and because the emphasis on refactoring allows developers to fix design weakness as theri understanding of the domani improves.

• TDD is not only about testing!
• TDD is also bout design and documentation!
• Writing the test cases for a class gives you the püoint of view of its clients.
• TDD helps you design loosely coupled systems
• Building a comprehensive test harness enables you to refactor safely as your system grows!

If you test a class in its natural environment (Collaborating classes, database and network ressource) its always possible that, if a bug is found, its not really identified that the testet class generates the bug but also the connected ressources. Therefore it helps to test the class which is wanted to be tested in an isolated (fake) environment. Alos called test it with Mock Objects.

By testing an object in isolation the programmer is forces to consider an object's interactions with its collaborators in the abstract, possibly before those collaborators exist.

TDD with Mock Objects guides interface design by the services that an object requires, not just those it provides. This process results in a system of narrow interfaces each of which defines a role in an interaction between objects, rather than wide interfaces that describe all the features provided by a class. We call this approach Need-Driven Development.

• Code that has value...
• Code that we inherited...
• Code that is not fully documente, not necessarily perfectly designed...
• Or just: LEgacy code is code without tests.

Code without tests is bad code. It doesn't matter how well written it is. it doesn't matter how pretty or object-oriented or  well-encaplusated it is. With tests, we can change the behavior of our code quickliy and verifiably. Without them, we really don't know if our code is getting better or worse.

• Edit and pray
  • Work with extreme care
• Cover and modify
  • Work with a safety net - a test harness

• Identify change points
  • What part of the system do i need to change in order to add the feature of ix the bug?
• Find test points
  • Where i will write the test coe, i.e. what classes and methods do i need to test to validate my change?
• Break dependencies
  • How do i modify the code, so that a compnonent can be tested in isolation?
• Write tests
• Make changes and refactor

Most applications are glued together. But we don't know this until we try to test pieces in isolation.

• Two reasons for breaking dependencies in legacy code:
  • Sensing: we break dependencies to get some visibility into what the code is actually doing.
  • Separation: we break dependencies to be able to test a piece of code in isolation (without taking all collaborating classes into the test harnesss)

• Singletons
  • If there can only be one of an object you'd better hope that it is good for your tests too
• Intenal instanciations
  • When a class creates an instance of a hard coded class, you'd better hope that class runs well in tests
• Concrete dependencies
  • When a class uses a concrete class, you'd better hope that the class lets you know what is happening to it

• A seam is a place where you can alter behavior in your program without editing in that place.
• Every seam has an enabling point, a place where you can make the decision to use one behavior or another.
• Seam model types:
  • The Object Seam
  • The Pre-Processing Seams
  • Link Semas ( the Java classpath can be an enabling point)

Scenario: I need to change a monster method and can't write tests.

Dependency Breaking Techniques:

• Extract and override Call
  • When we have a bad dependency in a method and it is represented as a call. We can extract the call to a method and then override it in a testing subclass.
  • Steps:
    • Extraxt a method for the call (remember to preserve signatures)
    • Make the method virual
    • Create a testing subclass that overrides that method
  • Extract and override factory Method
  • Identify an object creation in a constructor
  • Extract all of the work involved in the creation into a factory method
  • Create a testing subclass and override the factory method in it to avoid dependencies on pfoblematic types unter test
• Extract interface
  • *A key refactoring for legacy code*
  • Safe
    • With a few rules in mind you can do this without a chance of breaking your software
  • Can take a little time
  • Steps:
    1. Find the member-functions that your class uses from the target class
    2. Think of an interface name for the respnsibility of those methods
    3. Verify that no subclass of target class defines those functions non-virtually
    4. Create an empty interface class with that name
    5. Make the target class inherit from the interface class
    6. Replace all target class references in the client class with the name of the interface
    7. Lean on the compiler to find the methods ithe interface needs
    8. Copy function signatures for all unfoung dunctions to the new interface. Make them pure vitual.
• Parameterize Method
  • If a method has a hidden dependency on a class because it instantiates it, make a new method that accepts an object of that class an an argument
  • Call it from the other method
  • Steps:
    • Create a new method with the internally created object as an argument
    • Copy the code from the original method into the old method, deleting the creation code
    • Cut the code from the original method and replace it with a call to the new method, using a "new wxpression" in the argument list
• Replace Global Refence with Getter

• Adding tests to legacy code might be hard
• Breaking dependencies is an essential task
  • makes code testable
  • improves the design of the code
• A systematic approach fo adding test is essential

Set of established architectural organizations - coompnents, relationships, connectors, ...

• Patterns:
  • Includes well-known organizational stuctures such as: e.g. layered systems, pipes and filters, etc.
• Reference Models:
  • Prescribes specific vonfigurations of components and interactions such as: e.g. ISO OSI 7-layer reference model

Most important:

• Descriptions of successful engineering stories
• Address recurring problems
• describe generic solutions that work

But also:

• Tell about the forces of the problem
  • What makes the problem addressed hard?
• Tell about the engineering trade-offs to take
  • Benefits and liabilites/consequences
• Give us names to talsk with and about