1. CS189A/172 - Winter 2008 Lecture 7: Software Specification, Architecture Specification

2. Software Specification In different phases of the software process we need ways to specify the deliverable for that phase –Need to specify the requirements Which is what you are doing in SRS –Need to specify the design We need to document and communicate the design –Need to specify the implementation Comments Assertions

3. Specification Languages Main issue: When you write code you write it in a programming language –How do you write the requirements? –How do you write the design? Specification languages –Used to specify the requirements or the design –As we have seen parts of SRS are necessarily in English (customer has to understand). To bring some structure to the SRS you can use semi-formal techniques such as use-case diagrams. Depending on the application you maybe able to use formal techniques too –For design you can use UML class diagrams, sequence diagrams, state diagrams, activity diagrams –Some specification languages (such as UML class diagrams are supported with code generation tools)

4. Specification Specifications can be –Informal No formal syntax or semantics –for example in English Informal specifications can be ambiguous and imprecise –Semiformal Syntax is precise but does not have formal semantics UML (Universal Modeling Language) class diagrams, sequence diagrams –Formal Both syntax and semantics are formal Z, Statecharts, SDL (Specification and Design Language), Message Sequence Charts (MSC), Petri nets, CSP, SCR, RSML

5. Ambiguities in Informal Specifications The input will be a string or a number –The input will be a string or a number or both –The input will be a string or a number but not both The number of songs selected should be less than 10 –strictly less than? less than or equal? The user has to select the options A and B or C –“(A and B) or C”, “A and (B or C)”

6. Formal Specifications: A Success Story Requirements State Machine Language (RSML) –A formal specification language based on hierarchical state machines (statecharts) The developers of RSML applied it to the specification of Traffic Collision Avoidance System (TCAS) to demonstrate benefits of using RSML [Leveson et al. 1994] –TCAS: the specification of a software system which is required on all aircraft in USA carrying more than 30 passengers During the specification of TCAS in RSML ambiguities were discovered in the original English specification of TCAS –Eventually FAA decided to use the RSML versions of the TCAS specification

7. Example Formal Specification Formal specifications avoid ambiguity –However, they could be hard to understand –And it is not easy to write formal specifications Let’s try to specify a sorting procedure formally (mathematically) I will just use basic Math concepts: functions, integers, arithmetic –Input: I : An array of size n of integers How do we formally specify what an array is? I : Z  Z (a function from integers to integers) I : 1... n  Z n  1

8. Example: Sorting –Output: O : 1... n  Z  i, O(i)  O(i+1)  i, 1  i  n  O(i)  O(i+1)  i, 1  i  n  O(i)  O(i+1) (  i, 1  i  n  O(i)  O(i+1))  (  i, 1  i  n  (  j, 1  j  n  O(i) = I(j))) (  i, 1  i  n  O(i)  O(i+1))  (  i, 1  i  n  (  j, 1  j  n  O(i) = I(j)))  (  i, 1  i  n  (  j, 1  j  n  I(i) = O(j))) (  i, 1  i  n  O(i)  O(i+1))  (  f : 1... n  1... n, (  i, j, (1  i  n  1  j  n  i  j)  f(i)  f(j))  (  i, 1  i  n  O(i) = I(f(i))))

9. Architecture Specification There are several Architecture Description Languages (ADLs) that have been proposed –See “A Classification and Comparison Framework for Software Architecture Description Languages,” N. Medvidovic, R. N. Taylor, IEEE Transactions of Software Engineering, vol. 26, no. 1, pp. 70-92, 2000. The basic concepts in specification of software architecture are: –Components: Components represent either major computational elements or data stores. They are usually represented with boxes in visual representation of architectures. –Connectors: Connectors represent interactions among components. They are usually represented as lines in visual representations –Systems: Systems correspond to different configurations of components and connectors.

10. Architecture Specification Most architecture specification languages support –hierarchical specification where one component contains a sub- architecture that is specified separately –specification of component interfaces which consist of ports ports are the points where the connections are made ports can be classified as input and output ports –specification of connector roles when a connector is connected to a port, it assumes a role such as source, sink, reader, writer, caller, readee, writee, callee, etc. –both graphical and textual specification of systems that consist of components and connectors –specification of additional constraints on components and connectors

11. Client Server Architecture ClientServer request Components Connector In addition to this diagram, the architecture specification should Explain the basic functionality of the Server and the Client –What do they do? What do they compute? What do they store? Explain the type of the connector –Is it an RPC connection or is it a socket connection, etc.? Explain the contents of the data (messages) exchanged between the Client and the Server Ports

12. A Case Study: Compiler I will use several block diagrams to explain the architecture of a compiler Although compilers are complicated software applications their basic architecture can be explained –using block diagrams that consist of components and connectors –listing key functionality of each component Even if you have not taken a course on compilers, after going through the following several slides you should have a good idea about the typical compiler architecture

13. A diagram showing the compiler as a single component with three ports (input, output, and error) A compiler recognizes legal (and illegal) source programs and translates them to the target language A Case Study: Compiler Source code Machine code Compiler Errors

14. A Higher Level View of a Compiler Compiler Preprocessor AssemblerLoader/Linker skeletal source program target assembly program relocatable machine code library routines, relocatable object files generates machine code from the assembly code collects the source program which may be divided into separate files macro expansion links the library routines and other object modules generates absolute addresses source program absolute machine code

15. Compiler Architecture Compiler uses an intermediate representation ( IR ) Front end maps legal source code into IR Back end maps IR into target machine code The middle end optimizes the generated code by analyzing and transforming the IR Different phases of compiler also interact through the symbol table Symbol Table Errors Middle End Source code Front End Machine code Back End IR

16. Architecture of the Front End The front end Recognizes legal programs Reports errors for the illegal programs in a useful way Produces IR and construct the symbol table Source code Scanner IR Parser tokens IR Type Checker Errors

17. Architecture of the Back End The back end Translates IR into target machine code Chooses instructions to implement each IR operation Decides which values to keep in registers Schedules the instructions for instruction pipeline Errors IR Instruction Scheduling Instruction Selection Machine code Register Allocation IR

18. Architecture of the Middle End The middle end is organized as a series of phases where each phase transforms the IR to optimize the generated code Typical optimization transformations include Discover and propagate constant values Move a computation to a less frequently executed place Discover a redundant computation and remove it Remove unreachable code Errors Opt 1 Opt 3 Opt 2 Opt n... IR