STURDY SOFTWARE DEVELOPMENT WATERFALL

What is the Waterfall Model?

The first formal description of the Waterfall model is often cited as a 1970 article by Winston W. Royce. The waterfall model is a sequential software development process. It includes 5 main phases that should be followed in order. They are as follows: 1. 2. 3. 4. 5. Requirements Design Implementation Verif ication Maintenance

Requirements
In this phase team should try to figure out a complete description of the behavior of a system to be developed and predict the system requirements.

Design
In this phase designers will come up with a software blueprint for developers to implement. The requirements, that are gathered in the previous phase are broken down into logical units, so that the implementation would be easier. Many aspects should be taken into consideration, such as security, compatibility, and extensibility. The Design team can use a Modeling language such as UML to describe software both structurally and behaviorally.

Implementation
In this phase the actual development of the software takes place. (Coding phase)

Verification
Testing phase to find bugs or performance issues.

Maintenance
After the deployment of the software, routine maintenance work is carried out.

Waterfall's Advantages
More time will be spent early in the software production cycle. If a bug is found in the early stages (such as requirements specif ication or design) it is cheaper in terms of cost, effort, and time, to fix than the same bug found later on in the process. (Rule #3b from the lectures). It is also beneficial because every stage in the process has a defined start and a defined end. Thus, it is easier to know when you are done it is easier to track progress, easier to figure out what your productivity level is. You are also able to coordinate a large team, that is distributed along the country, so one team can work on on part and the other can work on the other part.

Waterfalls Drawbacks
A drawback is that the cycle is too linear. For example suppose that you find a bug that wasn't in your design until the verif ication phase, at which point it is really costly to go back, because you have to change your design, and reiterate through the whole process again. It also lacks flexibility. For example if a client changes his mind or wants to add a new function to the software (which was not predicted in the requirement and design phases), the team should go over all of the stages again.

Modified Waterfall Method

The Modif ied Waterfall Method is like the Waterfall method but it allows you to go back after each phase. It allows better testing since after finding a bug you should not necessarily return to the first stage. better testing leads to the better implementation.

Why use Waterfall?

Basically you use Waterfall model when you have a low complexity, short duration program. For example fixing bugs or adding enhancements to a existing program. It is also good for heavily regulated projects like nuclear control ( in which you need to monitor very carefully every aspect of the program). Other examples would be, military systems, and health care systems. The telecommunications industry also uses this because they find it efficient and exact.

So is the Waterfall Model Practical?

It is not practical if you use this model to design a code for a large system, however, if you're doing a small program to just do a specif ic task, yes this model can be used.

SPIRAL WATERFALL MODEL

It was defined by Barry Boehm in 1986. This model of development combines the features of the prototyping model and the Waterfall model. In general it is more flexible than Waterfall.

The Four Stages of the Spiral Model

The spiral waterfall method has four main stages and it iterates through them. In each iteration an even more complex version of the product will be released. The stages are as follows: 1. 2. 3. 4. Determine objectives Identify and resolve risks Development and testing Plan for the next iteration

Determine Objectives
The team starts off with determining user objectives, they then ask the user what they need, and design a loose high level design that outlines the function of the entire program. This is analysis or requirements stage in the Waterfall method.

Identify and Resolve Risks

This is the most important stage of the Spiral design. It is where you actually go ahead and lay out your prototype in UML, which is again similar to the design phase in Waterfall.

Development and Testing

In this stage the team actually take the prototype that they outlined and implement it and test it to make sure that it works.

Plan for the Next Iteration

This is where Spiral breaks from Waterfall model. In Waterfall we dont plan for the next iteration. In this stage you show off what you got done to the client, assess their feedback, and use the information you gather for your next planning sessions, where you go back and repeat all the stages again.

When to use the Spiral Model?

It is used for large scale high budget projects. The Spiral model is mostly popular among the military and video game designers. The Spiral model is preferred in these cases because these kinds of projects benefit from having a solid plan and frequent communication between separate teams as often as possible. In addition, in the event that your company is kind of chaotic you can use the Spiral design to ensure that you have a solid plan for at least the next year.

A note on Waterfall vs. Spiral

In Waterfall you spend a signif icant amount of time trying to predict the projects requirements. But most of the time, regardless of the time you have spent, the project specif ication may change. A team which is working with a Waterfall method has to spend a lot of time and try to predict all of the requirements, then move to the design stage and try to do all the design and so on. Instead of that, in the Spiral method, you try to make an implementation, and then you can go back and use that implementation to re-modify your

requirements and make another implementation, use that to make another implementation and so on. It is like the automotive industry, where they try to make many working versions of the working car before they make the version of the car which is actually shipped. Note that in Spiral model, in each iteration you have to create a new version of the every stage.

Spirals Drawbacks
It is less viable for smaller scale projects, because it is intended to be long term. A single design cycle is intended to take from six months to two years, this is great for a long term military project but not so much for a small consumer project that you want out within two years.

STRUCTURE SYSTEMS ANALYSIS AND DESIGN METHOD (SSADM)

Structured Systems Analysis and Design Method (SSADM) is a systems approach to the analysis and design of information systems. SSADM can be thought to represent a pinnacle of the rigorous document-led approach to system design. The three most important techniques that are used in SSADM are:

Logical Data Modeling: This is the process of identifying, modeling and documenting the data requirements of the system being designed. The data are separated into entities (things a business needs to record information about) and relationships (the associations between the entities). Data Flow Modeling: This is the process of identifying, modeling and documenting how data moves around an information system. Data flow modeling examines processes (activities that transform data from one form to another), data stores (the holding areas for data), external entities (what send data into a system or receives data from a system), and data floes (routes by which data can flow). Entity Behavior Modeling: This is the process of identifying, modeling and documenting the events that affect each entity and the sequence in which these events occur.

Stage 0 - Feasibility Study

For a large project, in order to determine whether or not the project is feasible, there must be some form of investigation into the goals and implications of the project. For very small scale projects this may not be necessary as the scope of the project is easily apprehended. This feasibility study may be done informally either because there is not time for a formal study or because the project will be done one way or the other. When a feasibility study is carried out, there are four main areas of consideration: Technical - is the project technically possible? Financial - can the business afford to carry out the project? Organizational - will the new system be compatible with existing practices? Ethical - is the impact of the new system socially acceptable?

The steps of this stage are: a. Define the Problem: This step is concerned with gaining a good understanding of the business and information needs of the business area under consideration. It highlights unsatisfactory services within the current environment and additional functions and data required in the new environment. The purpose of this step is to investigate to a level of details that allow the key requirements which determine the feasibility options to be defined. b. Select Feasibility Options: The feasibility options defined in this step are possible logical solutions to the requirements described in the user requirements. This step aims to develop several options that meet the defined requirements, from which users can select. To answer these questions, the feasibility study is effectively a condensed version of a fully-blown systems analysis and design. The requirements and users are analyzed to some extent, some business options are drawn up and even some details of the technical implementation. The product of this stage is a formal feasibility study document.

Stage 1 - Investigation of the Current Environment

This is one of the most important stages of SSADM. By coming to a full understanding of the data requirements at an early stage, the remaining analysis and design stages can be built up on a firm foundation. During this stage, detailed requirements are collected and models of the business are built. These models will include existing clerical and IT systems, as well as planned business procedures and information needs. In almost all cases there is some form of current system even if it is entirely composed of people and paper. Through a combination of interviewing employees, circulating questionnaires, observations and existing documentation, the analyst comes to full understanding of the system as it is at the start of the project. This serves many purposes: The analyst learns the terminology of the business, what users do and how they do it The old system provides the core requirements for the new system Faults, errors and areas of inefficiency are highlighted and their reparation added to the requirements The data model can be constructed The users become involved and learn the techniques and models of the analyst The boundaries of the system can be defined

To produce the models, the analyst works through the construction of the models. The first set of data-flow diagrams (DFDs) are the current physical model, that is, with full details of how the old system is implemented. The final version is the current logical model which is essentially the same as the current physical model but with all references to implementation removed together with any redundancies such as repetition of process or data. In the process of preparing the models, the analyst will discover the information that makes up the users and requirements catalogues. All the constraints and problems are recorded alongside other system objectives in the User Requirements. The steps involved in this stage are: a. Develop Business Activity Model: A model of business activity is built. Business events and business rules would also be investigated as an input to the specif ication of the new automated system. b. Investigate and Define Requirements: The objective of this step is to identify the problems associated with the current environment that are to be resolved by the new system. It also aims to identify the additional services to be provided by the new system and users of the new system. c. Investigate Current Processing: It investigates the information flow associated with the services currently provided, and describes them in the form of Data Flow Model. At this point, the Data Flow Model represents the current services with all their deficiencies. No attempt is made to incorporate required improvement, or new facilities. d. Investigate Current Data: This step is to identify and describe the structure of the system data, independently of the way the data is currently held and organized. It produces a model of data that supports the current services. e. Derive Logical View of Current Services: The objective of this step is to develop a logical view of the current system that can be used to understand problems with the current system. The products of this stage are:

Users Catalog describing all the users of the system and how they interact with it Requirements Catalog detailing all the requirements of the new system Current environment logical data structure (ERD) Context diagram (DFD) Leveled set of DFDs for current logical system Full data dictionary including relationship between data stores and entities

Stage 2 - Business System Options

Having investigated the current system, the analyst must decide on the overall design of the new system. To do this, he or she, using the outputs of the previous stage, develops a set of business system options. These are different ways in which the new system could be produced varying from doing nothing to throwing out the old system entirely and building an entirely new one. The analyst may hold a brainstorming session so that as many and various ideas as possible are generated. To assist the management to make a sound choice, a number of business system options, each describing the scope and functionality provided by a particular development / implementation approach, are prepared and presented to them. The ideas are then collected to form a set of two or three different options which are presented to the user. The options consider the following: The degree of automation The boundary between the system and the users The distribution of the system, for example, is it centralized to one office or spread out across several? The cost/benefit The impact of the new system

Where necessary, the option will be documented with a logical data structure and a level 1 data-flow diagram. These options may be supported by technical documentation such as Work Practice Model, Logical Data Model and Data Flow Model. They also require financial and risk assessments to be prepared, and need to be supported by outline implementation descriptions. The steps of this stage are: a. Define BSOs: This step is concerned with identifying a number of possible system solutions that meet the defined requirements from which the users can select. b. Select BSOs: This step is concerned with the presentation of the BSOs to users and the selection of the preferred option. The selected option defines the boundary of the system to be developed in the subsequent stages. The users and analyst together choose a single business option. This may be one of the ones already defined or may be a synthesis of different aspects of the existing options. The output of this stage is the single selected business option together with all the outputs of stage 1.

Stage 3 - Requirements Specification

The objective of this stage is to specify in details the processing and data requirements of the option selected. This is probably the most complex stage in SSADM. Using the requirements developed in stage 1 and working within the framework of the selected business option, the analyst must develop a full logical specif ication of what the new system must do (what the system will do, not how it will do it). The specif ication must be free from error, ambiguity and inconsistency. To produce the logical specif ication, the analyst builds the required logical models for both the data-flow diagrams (DFDs) and the entity relationship diagrams (ERDs). These are used to produce function definitions of every function which the users will require of the system, entity life-histories (ELHs) and effect correspondence diagrams. These are models of how each event interacts with the system, a complement to entity life-histories. These are continually matched against the requirements and where necessary, the requirements are added to and completed. The steps of this stage are: a. Define Required System Processing: This step is to amend the requirements to reflect the selected Business System Option, to describe the required system in terms of system data flows and to define the user roles within the new system. b. Develop Required Data Model: This step is undertaken in parallel with the above step. The Logical Data Model of the current environment is extended to support all the processing in the selected Business System Option. c. Derive System Functions: During the parallel definition of data and processing, additional events are identif ied, which cause existing functions to be updated, and new functions to be defined. Service level requirements for each function are also identif ied in this step. d. Develop User Job Specif ications: A Work Practice Model is developed to document the understanding of the user jobs in concern. e. Enhance Required Data Model: Its objective is to improve the quality of the required system Logical Data Model by the application of relational data analysis (also known as normalization). f. Develop Specif ication Prototypes: It is used to describe selected parts of the required system in an animated form, for demonstration to the users. The purpose is to demonstrate that the requirements have been properly understood and to establish additional requirements concerning the style of the user interface. g. Develop Processing Specif ication: This step is principally concerned with defining the detailed update and inquiry processing for the required system. h. Confirm System Objectives: During stages 1 and 3, the requirements will have been recorded, as they are identif ied, in the user requirements. This step represents the final review of the requirements before the completion of the definition of requirements stage. The product of this stage is a complete Requirements Specif ication document which is made up of: The updated Data Catalog The updated Requirements Catalog The Processing Specif ication which in turn is made up of User role/function matrix Function definitions Required logical data model Entity life-histories Effect correspondence diagrams

Stage 4 - Technical System Options

This stage is the first towards a physical implementation of the new system. Like the BSO, in this stage a large number of options for the implementation of the new system are generated, possibly including the "no change" option (i.e. using the existing system architecture). This is honed down to two or three to present to the user from which the final option is chosen or synthesized, based on the parameters of the cost of producing each one to a useful level of detail, the need to demonstrate practicality, and the scope for exploring alternative approaches. However, the considerations are quite different being: The hardware architectures The software to use The cost of the implementation The staffing required The physical limitations such as a space occupied by the system The distribution including any networks which that may require The overall format of the human computer interface

The steps of this stage are: a. Define TSOs: Its purpose is to identify and define the possible approaches to the physical implementation to meet the function definitions. It also validates the service level requirements for the proposed system in the light of the technical environment b. Select TSO: This step is concerned with the presentation of the TSOs to users and the selection of the preferred option. All of these aspects must also conform to any constraints imposed by the business such as available money and standardization of hardware and software. The output of this stage is a chosen technical system option.

Stage 5 - Logical Design

The objectives of this stage are to design the menu structure and dialogues of the required system, and to specify the update/inquiry process modules. Though the previous level specif ies details of the implementation, the outputs of this stage are implementation-independent and concentrate on the requirements for the human computer interface. The three main areas of activity are the definition of the user dialogues. These are the main interfaces with which the users will interact with the system. The logical design specif ies the main methods of interaction in terms of menu structures and command structures. The other two activities are concerned with analyzing the effects of events in updating the system and the need to make inquiries about the data on the system. Both of these use the events, function descriptions and effect correspondence diagrams produced in stage 3 to determine precisely how to update and read data in a consistent and secure way. The steps of this stage are: a. Define User Dialogue: This step defines the structure of each dialogue required to support the on-line functions and identif ies the navigation requirements, both within the dialogue and between dialogues. b. Define Update Processes: This is to complete the specif ication of the database updating required for each event and to define the error handling for each event. c. Define Inquiry Processes: This is to complete the specif ication of the database inquiry processing and to define the error handling for each inquiry. The product of this stage is the logical design which is made up of: Data catalog Required logical data structure Logical process model which includes dialogues and model for the update and inquiry processes

Stage 6 - Physical Design

This is the final stage where all the logical specif ications of the system are converted to descriptions of the system in terms of real hardware and software. The objective of this stage is to specify the physical data and process design, using the language and features of the chosen physical environment and incorporating installation standards. The logical data structure is converted into a physical architecture in terms of database structures. The exact structure of the functions and how they are implemented is specif ied. The physical data structure is optimized where necessary to meet size and performance requirements. This stage addresses the following activities: a. Prepare for Physical Design: * Learn the rules of the implementation environment * Review the precise requirements for logical to physical mapping; and * Plan the approach b. Complete the Specif ication of Functions c. Incrementally and Repeatedly Develop the Data and Process Designs The product of this stage is a complete Physical Design which could tell software engineers how to build the system in specif ic details of hardware and software and to the appropriate standards.

Advantages and Disadvantages

Using this methodology involves a signif icant undertaking which may not be suitable to all projects.

Advantages
Three different views of the system Mature Separation of logical and physical aspects of the system Well-defined techniques and documentation User involvement Better communication within the team

Disadvantages
The size of SSADM is a big hindrance to using it in all circumstances. There is a large investment in cost and time in training people to use the techniques. The learning curve is considerable as not only are there several modeling techniques to come to terms with, but there are also a lot of standards for the preparation and presentation of documents.

DEVELOPMENT TOOLS AND CONCEPTS (Repositories, CVS, SVN, building, branching, tags, trunks, tickets) Repository
A repository refers to a central place where data is stored and maintained. It can be a place where multiple databases or files are located for distribution over a network. With reference to CSC301, all our source code, documentation and tests for the group projects will be stored in a repository. This ensures the files are accessible to all the members of the group, the Scrum master and the Steve - the instructor.

Version Control Systems

It is software with the purpose of having a measurable, and specif ic way of tracking progress and various changes to a project. Changes made are usually identif ied by a revision number. All users that have access to the repository to make changes to the files using a set of commands defined by the version control system.

Why use a repository and Version Control System?

Collaborating on programs and documents will be a hassle if we have to send the documents over email or using some other obscure method. A plausible solution will be to have a central place where all the documents are stored so that all the collaborators can edit and modify the central copy. However, it will be disastrous if two or more collaborators can edit the central copy directly because if one of the collaborators makes a bad change, the copy that the other collaborator(s) are currently working on will have changed. Hence the need for a central repository and a version control system so that collaborators can checkout the repository, make changes to their local copy and submit the wanted changes.

Concepts
Trunk / Master / Devel
Usually refers to the main development branch New code usually gets committed here Tends to be the most active branch

Branch
What is a branch? A particular instance of a project, that has been duplicated and split (usually from the main development branch) It is distinct from the main branch, and can be developed at a different rate

Why use a branch? Used to begin adding experimental features to code that may require large modif ications Often best to do such changes so they do not interfere with regular flow of development Most often branches are merged back into the main development branch

Tag
What is a tag? A reference to the state of the code at a certain point in time Can be thought of as a "snapshot" of the code

Why use a tag? Used to mark the code (usually at a certain commit) for release Can also be used to mark particular milestones.

Merging
What is merging? Combination of 2 or more versions of the same set of files into one set that contains the changes introduced by each version Merges can succeed (if there were no conflicts among version), or can require intervention from a developer to resolve a failed merge

Why use merging? Most branches usually contain features not yet in trunk, so should be merged into trunk A necessity when working with different people who are modifying the same segments of code

Examples of Version Control Systems (Subversion and Concurrent Versions System).

The most commonly used Version Control Systems are SVN and CVS. CVS is based on Revision Control System (RCS) files of versions control. Each file connected to CVS is an ordinary file containing some additional information. SVN is implemented as a relational database.

Common SVN and CVS Commands.

checkout add delete status log update commit diff move import export merge

Conceptual differences between SVN and CVS.

1 Revision Numbers
In SVN, the repository looks like a single filesystem. Each commit results in an entirely new filesystem tree; in essence, the repository is an array of trees. Each of these trees is labeled with a single revision number. When someone talks about revision 54 they're talking about a particular tree. In CVS, revision numbers are per-file because it uses RCS as a backend where each file has a corresponding RCS file in the repository and the repository is laid out according to the structure of the project tree.

2 Meta data
SVN allows to "attach" to a file any number of all possible named attributes. CVS allows to store of only files and nothing else.

3 Supported file types.

SVN manipulates all the file types and does not require your instructions. CVS was initially intended for text data storage. Hence storage of other files (binary, unicode) is not trivial and requires special information, as well as adjustments on either server or client sides.

4 Speed.
SVN really works faster than CVS. This is because it transmits less information through the network and supports more operations for offline mode. CVS works more slowly.

5 Rollback.
SVN does not allow rollback of commit operations. Authors suggest copy good repository state to the end of trunk to overwrite bad commit. However bad commit itself will remain in repository. CVS allows to rollback any commit in the repository, even if this may require some time (each file should be processed independently)

6 Atomic commits.
SVN allows atomic commits so if an error occurs during committing, SVN automatically tries again. CVS however does not have atomic commits.

Communication in Software Development

Communication is very important in Software development, especially in Agile Development methodologies. Why is communication an issue worth discussing? Because the need to communicate effectively pervades software development, operations, and support. Developers and users must communicate. Developers and operations staff must communicate. Developers and management must communicate. Developers and well, you get the idea.

Types of communication
1. 2. 3. 4. 5. 6. 7. 8. 9. Face-to-face at whiteboard Face-to-face conversation Video conversation Phone conversation Email conversation, chat Instant messaging Video tape Audio tape Wiki (provides documentation, notes)

10. DrProject (combines most of the above) Table 1. Effectiveness of communication strategies on agile development teams. From Ambysoft 2008 Agile Principles and Practices survey. Range of answers from -5(very ineffective) to +5 (very effective). Communicaion Strategy Face to Face Face to Face at Whiteboard Overview diagrams Online chat Overview documentation Teleconference calls Videoconferencing Email Within Team 4.25 4.24 2.54 2.10 1.84 1.42 1.34 1.08 With Stakeholders 4.06 3.46 1.89 0.15 1.86 1.51 1.62 1.32

Factors Effecting Communication

1. 2. 3.

Physical Proximity. The closer people are to one another the greater the opportunities for communication. At one end of the spectrum two people can be working side-by-side pair programming at the same workstation and at the other end of the spectrum two people can be in different buildings. Temporal Proximity. Whether or not two people are working at the same time affects communication. You may be separated from some of your co-workers by several time zones, it is quite common for North American firms to outsource development work to Asian or European companies, or even simply by different personal schedules. Amicability. Cockburn believes that amicability, the willingness of someone to hear the thoughts of another person with good will and to speak without malice, is an important success factor. The greater the amicability a greater amount and quality of information will be communicated and less will be concealed. Amicability is closely by the trust that people have for one another and the sense of community that they share. Cockburn reports that sometimes amicability can run too high, people can be so worried about offending their colleagues that they are afraid to disagree with them or be afraid to take the initiative for fear of being perceived as glory seekers.

Communication Technologies
Communication technologies are designed to increase communication productivity. Use simplest tools that are best for your task. Table 2. Communication Technologies. Technology Collaborative modeling tools Collaborative writing tools Discussion Tools Version control tools Virtual meeting tools Description CASE tools that enable several developers to simultaneously work on one or models with real-time updates of those models. Word processing tools that enable several people to simultaneously write a document with real-time updates of that document. Tools such as email, newsgroups, mailing lists, instant messaging, and chat rooms that enable transmission of text messages, and potentially other attachments, between people Software tools used to check in/out, define, and manage versions of project artifacts. Tools that enable communication between several people who are in different physical locations.

Effective Communication
When is communication most effective? When people are willing to work together and do what it takes to get the job done. This is why Agile Methodogies' principle of Open and Honest Communication is important because if you dont trust the information that you are receiving, or for that matter the people that are providing it to you, then your goal of effective communication is lost. The concept that everyone can learn from everyone else is critical to your success because it defines a mindset that enables communication someone who believes they can learn something from the person(s) they are communicating with are much more receptive than someone who believes otherwise. Effective communicators realize that the goal is to share information, and that this information sharing is typically a two-way street. Another important success factor is your ability to pick the right mode of communication (face-to-face, etc.). Finally, you need a positive view of documentation. Documentation can either be good or bad, therefore you should strive to stick with the good and avoid the bad.

DrProject
DrProject is a communcation technology that integrates revision control, issue tracking, mailing lists, a wiki, and other tools that software development teams need to succeed. DrProject has: Group mailing list Event log Source code by revision

Ticketing (to-do list, way to look into the future of project, ticket every task) ..., etc.

Creating a new ticket involves: Specifying owner Specifying type of ticket: bug, new feature Importance and effort required Estimated due date

REFERENCES
1. Scott W. Ambler. "Communication on Agile Software Projects." http://www.virtualsalt.com/mla.htm

IDE - Integrated development environment

Software application which provides comprehensive facilities to computer programmers for software development Consists of Editor Compiler or interpreter Debugger Build automation tools (testing tools, documentation tools etc. ) Some other useful tools (GUI builders, class browser etc. )

Most popular IDEs Eclipse Netbeans Wing Visual Studio

IDEs such as Eclipse and Netbeans support multiple languages. Support is often done through plugins. After installing a plugin, a programmer can switch between programming languages by choosing a different "prospective". There are also IDEs(DrJava, Wing) designed to support only one particular language. Some IDEs(Netbeans, Eclipse, Lazarus etc.) are developed using cross-platform language (Java) and run on different platforms such as Windows, Linux and Mac OS. Some IDEs are platform specif ic. Sometimes version control tools are integrated into IDEs to simplify project management.

Requirement specification and elicitation

User stories
User stories are a few sentences that state what the user wants. They are normally written by the customers. They are meant to help respond to fast over head. They are used to help get rid of large documents. They are generally written on 3 by 5 index cards. They are used to generate time estimates. They prioritize development activities. They set the difficulties of the tasks by Fibonacci's sequence. Generally written informally but may also be a formal specif ication. General format "As a <role>, I want <goal/desire>" Example: "As a teacher, I want to be able to book a lab room."

Tech Specifications
List of very specif ic, low-level requirements and clearly defined acceptance standards. They are not abstract; however, cannot delve too much into system internals. Software Requirement Specif ication (SRS) are detailed documents enumerating a company's understanding of all the aspects of a project (at a certain point in time; generally during the design phase, i.e. before the actual development starts). Software developers are generally responsible to write SRS because it assures both the client and the developers outline the requirements from a different perspective. This helps the developers understand what the client actually wants, so that no time will be wasted in developing wrong softwares. Storyboard Most people already have an understanding of what a storyboard is and how they are used in media, such as cartoons or movies. The writers for a cartoon show give the artists an idea. The artists interpret the idea and create a storyboard before committing to making the episode; the writers will ensure the storyboard represents what they want and tell this to the artists so the necessary changes can be made. The artists will then create something very close to the writer's original idea as opposed to their (perhaps false) interpretation of it. Obviously, this saves a massive amount of effort and time. The above is analogous to software design. Using a storyboard can: Help communicate what a client wants. Strip away ambiguities. Ensure a program looks and functions like a client imagines it will. Ensure that the program tailors to its user's needs. Using storyboards for software design is very easy: During meetings with clients, ask clients to draw a rough GUI of how they want their program to look. As a program progresses, take screenshots of your program in action and ensure this is how the client wants your program to function. In addition, plan out storyboards of users using your program. For example, if your program does 3 different things, make storyboards of users going through the 3 cases and show them to your client. Always ensure that your program is adhering to your client's needs; using storyboards (and showing them to your client) can yield more information than just user stories.

Behavioural Requirements
A behavioural requirement is simply what the clients expects from the product.

Non-behavioural (Functional) Requirements

A non-behavioural requirements is more about the qualities of the overall system, 3 examples of these are Reliability It's not enough to show that your system can do something once. If a system does not work reliably then it's not going good, another closing related attribute is Security, so is the software system secure? Usability Is the product easily accessible to the user. For example, can the user use it through the internet or do they have to get some special browser to access product? Is the software user friendly? Efficiency This is quite important because even if the system is reliable, usable and fully functional and if it not efficient it is not good. For example, if the system works well for small inputs but works really bad for bigger inputs, the program is not efficient. Other requirements include maintainability, portability, flexibility, integrity, reusability, testability and much more. So essentially, non-behavioural requirements are characteristics of software which dont really change the behaviour or action of the system, So how do we handle these requirements, for this we can again use user stories, user stories can not only capture functional requirements it can capture all the non-functional requirements and any other added constraints. Sample user stories

As a customer, I want to be able to run your product on all versions of Windows from Windows XP onwards. As a user, I want the site to be available 99.999% of the time I try to access it so that I dont get mad. Tech Specs handles non-behavioural requirement it helps developers understand the performance expectations of the client, since they will have info about the system architecture.

Non-behavioural requirements are important because in many cases clients usually rate the system based on these non-behavioural requirements. For example, after developing a product with all its features working and after the client looks at it and complains "it is hard to work with this software". It would be bad on the development team, so for any system the success or failure of it depends highly on the usability, reliability and the other non-functional attributes of the software. So it is best to consider them in the development process and a good thing is to keep these requirements in mind while in the early stages of development because integrating them late in the development stage will be difficult and time consuming. When you add these expectations later, the developing may get harder or it may even be possible with the current state of the product. For example, the client may want the system to be faster and more user friendly than the previous version of the software. This could essentially change the language or even the architecture being used to make the system.

Requirement Elicitation:
How do we go about getting these requirements?
In reality, it is really hard to get these requirements from the clients, so the developers have to get these out of the clients through repeated and careful questioning. For example, the users may want the system to be really fast and use a certain amount of memory, these are expectation which are not directly conveyed by the users as requirements at least because the client assumes that the developers will take this into account while developing the system. After getting these requirements from the clients the developers while developing can check if they are doing anything against these requirements and make a better product, often a good strategy is the sample a few potential users to see how they would like this software to be, and ask questions like Would you like more user friendly, Would you like it to be faster than the previous version , in the general case a question would have the form would you like to have this attribute X Give the user feedback on time / cost for each feature so that they can make their mind on whether they want it or not. Most of the times, when the user gets to know how much extra it will cost to implement an exotic requirement, they will switch to a more general option.

UML - Unified Modeling Language

Standardized general-purpose modeling language Used to specify, visualize, construct, and document the design of an object-oriented system under development Combines techniques from data modeling(entity relationship diagrams), business modeling (work flows), object modeling, and component modeling Can be used anywhere in the software development cycle Offers a way to visualize various elements of a system such as activities, actors, business processes, database schemas, logical components, programming language statements, and reusable software components. Is an industry standard, and evolves under the supervision of the Object Management Group (OMG)

UML Diagram Categories

represents two different views on system models, each with 7 different diagrams static (or structural): uses objects, attributes, operations and relationships to emphasize the static structure.

dynamic (or behavioural): shows the collaboration among objects and changes to the internal states of objects to emphasize dynamic behaviour.

Static (structural) Diagrams

Class diagram: Shows the system's classes, their attributes, and relationships with other classes.

Component diagram: Shows how the system was split into components and the dependencies associated with each component

Composite structure diagram: Shows the class's internal structure and the collaborations that make this structure possible

Deployment diagram: Shows the hardware used in system implementations and the execution environments and artifacts deployed on the hardware

Object diagram: Shows a complete or partial view of a modeled system at a specif ic time

Package diagram: Shows how a system is split up into logical groups by showing the dependencies among these groups

Profile diagram: operates at the metamodel level to show stereotypes as classes with the <

Dynamic (behavioural) Diagrams

Activity diagram: Shows the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control

UML state machine: Shows the states and state transitions of the system

Use case diagram: shows the functionality provided by a system in terms of actors, their goals represented as use cases, and any dependencies among those use cases

Behaviour diagrams: these set of diagrams can be further split into the following diagrams Communication diagram: Shows the interactions between objects or parts in therms of sequenced messages. They represent a combination of information taken from class, sequence, and use case diagrams describing both the static structure and dynamic behaviour of a system

Interaction overview diagram: uses multiple diagrams to give an overview of the system

Sequence diagram: Shows how objects communicate with each other in terms of a sequence of messages. Also indicated the lifespans of objects relative to those messages.

Timing diagrams: a specif ic type of interaction diagram, where the focus is on timing constraints

Criticism of UML
Many of the diagrams used in UML are redundant or infrequently used Due to the poor writing of the UML standards, which is assumed to be the result of being written by a non-native English speaker, causes understanding of the UML model to NOT be clear. As Pitt would say, "We want to be clear and concise."

As with any modeling language, there are things that can be represented better then others by UML. In particular UML's problems stand out more as the implementation language of the system strays farther from orthodox object-oriented doctrine.

Structural Modeling
Class diagram Describes the structure of a system by showing the system's classes, their attributes, and the relationships among the classes. Component diagram describes how a software system is split up into components and shows the dependencies among these components. Composite structure diagram Describes the internal structure of a class and the collaborations that this structure makes possible. Deployment diagram Describes the hardware used in system implementations and the execution environments and artifacts deployed on the hardware. Object diagram Shows a complete or partial view of the structure of a modeled system at a specif ic time. Package diagram Describes how a system is split up into logical groupings by showing the dependencies among these groupings.

Static structures
Shows Entities that exist such as classes, interfaces, components, etc. Shows Relationships between entities. Shows Internal structure. Does not include information that changes with time, behaviour or runtime constraints.

Class Diagram
A graphical notation used to construct and visualize object oriented systems, includes a set of classes and the relationships between the classes.

Class components:
1. Name and stereotype Type may specify the role of the class Ex: "<< entity >> classname" 2. Attributes List of attributes and their type Each attribute specif ies it's visibility (such as public, private, etc) Ex: "+ Attr1 : int" 3. Operations List of functions that the class has, their parameters and return values Each function specif ies it's visibility Ex: "# Op1(in param1 : int, inout param2 : int*) : float" <<entity>> entity_name + attribute1 : int - attribute2 : float # attribute3 : Circle + opt1(in p1 : bool, in p2) : string - opt2(inout p3 : int) : float # opt3(out p6) : Class6*

Visibility of attributes and operations:

Attributes and operations in a class diagram are prefixed with symbols to denote their visibility "+" denotes public "-" denotes private "#" denotes protected Refer to the following table for the meaning of each access level Public "+" Yes Yes Yes Protected "#" Yes Yes No Private "-" Yes No No

Access Members of the same class Members of derived classes Members of any other classes

Operation parameter specification:

Parameters for each operation can be prefixed in different ways

"in" denotes that the parameter is not changed by the operation and is used as input "inout" denotes that the parameter may be changed by the operation an is also used as input "out" denotes that the parameter may be changed by the operation and will not be used as input

Relationships between classes:

Classes can be linked together to form relationships in the class diagram in several ways Inheritance (Generalization) relationship Represents a "is-a" relationship Classes are linked by a line with an open arrow pointing towards the parent of the inheritance

Simple Association Shown with a single line connecting the classes

Aggregation A type of association that represents a "part-of" relationship Classes are linked by a line with a diamond on the side of the parent class

Composition A type of association in which all parts are destroyed if the parent is destroyed Linked together by a line with a solid diamond pointing towards the parent

Dependency Exists between two classes if changes to the definition of one may cause changes to the other Shown as a dashed line with an arrow pointing towards the child

Class stereotypes:
Each class is associated with a stereotype that classif ies it based on its role Description Example

Stereotype

<<entity>> Represents the persistent information in a system <<boundary> Represents the interaction between a system an the > external world the coordination and sequencing of other <<control>> Models in the system objects

Classes that store information about an employee or student Classes that are responsible for communication with the user Classes that monitor main events and control flows by designating work to other classes

More on Behavioural Modeling and Behavioural Diagrams

Behavioural modeling evolved out of the the need for a more diverse way to capture software systems. It first started with State Machine Diagrams, and then through hybridization and the industry other behaviour models arose: - State Machine Diagrams (SMDs) - Use Case Diagrams (UCDs) - Activity Diagrams

State Machine Diagrams

SMDs are used to model a single object, by specifying the states an object can be in (as well as the actions that can cause an object to change states) throughout its lifetime. In this way, they are quite similar to FSAs (finite-state automata from CSC236), however they are more flexible. This flexibility has both advantages and disadvantages; while it made it easily adaptable for use across multiple industries, the modif ications to a SMD can become quite convoluted. There are three basic components to an SMD:

States represent the current state the object is currently in. In the example provided below, the 'Door' can either be 'Open', 'Closed', or 'Locked'. It is represented by a rectangle with rounded edges, and a label containing the name of the current state. Initial and Final States are represented by a solid black circle and a white circle with a black inner circle respectively. In the example below, the door begins 'Open' after it is first created. Transitions represent the change from one state to the next. It is represented by an arrowhead. It can optionally have a Trigger[Guard]/Effect, where the 'Trigger' is the event which causes the object to change state, the 'Guard' is the prerequisite that must be fulf illed to change state and the 'Effect' is an action which happens to the object as a direct consequence of changing state.

Use Case Diagrams

UCDs are actor-based, and everything is described as a relation between an actor and a task. They are also simple to use, hence they are frequently used in the real-world to confirm whether the specif ications match those of the clients'. There are two basic components to a UCD:

Actors represent anything external to the system, which can be people/hardware/other systems. It is represented by a stick figure with a label. Use Cases represent any single meaningful action in the system. It is represented by an eclipse.

These can be meaningfully connected with a single line (and an optional arrow, indicating the direction of control).

In the above example, we can see that a Food Critic can 'eat food', 'drink wine' and 'pay for food', whereas a Chef may only 'cook food'.

Activity Diagrams
Activity diagrams are used to describe a series of events and variations for one actor, or for programs, they can be used to demonstrate individual parts of a program and the flow of the program. There are specif ic guidelines which can be used to represent the decision paths in these series. These are the basic components of an Activity Diagram:

It is important to know the distinction between Merge and Join (which must have a preceding fork). Fork and Join are used for simultaneous events, and two events that end at a separate time cannot be 'joined'. Instead, they must be 'merged'.

The above is an example of an activity diagram that takes us through the process of ordering online.

Other General-purpose Modelling Languages

SysML XML

It is an extension of a subset of UML, allowing for the more precise of system models. It was designed to be less software-centric than UML It is sometimes used to model code use Schema.

LIMA Presentation on Tuesday October 26th.

Design Patterns Part 1.
This presentation is about learning what design patterns are and how they are useful.

Introduction.
Design patterns are used to solve a commonly occuring problem in software design. The main reason of coming up with a design pattern is to simplify the solution to many similar problems.

Brief History
Patterns originnated by Christopher Alexander in 1977. Kent Beck and Ward Cunningham were the ones experimenting in applying patterns to programming. Design Patterns gained popularity in computer science after the book: "Design Patterns: The elements of Reusable Object-oriented software" which was published in 1994 by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

Classification
There are 5 different categories of design patterns. 1. Creational Creational design patterns deal with object oriented mechanisms. Some examples of this kind of patterns are: Factory Pattern, Singleton Pattern 2. Structural Structural design patterns ease the design by identifying a simple way to realize relationships between entities. They specify relations between separate classes in a project. Some examples include: Adapter pattern, Bridge Pattern, Composite Pattern and Decorator Pattern. 3. Behavioral

Behavioral design patterns identify common communication patterns between objects and realize these patterns, increasing flexibility in carrying out this communication. Some examples are: Observer Pattern and Strategy Pattern. 4. Architectural Architectural design patterns are used for software architecture. One example is MVC. 5. Concurrency Concurrency design patterns deal with multithreaded programming paradign. REactor and Scheduler are two of the main examples.

Observer Pattern
As mentioned above the Observer Pattern is one of the behavioral patterns. It is used to define a one-to-many relationship between objects so that when one object changes, all its dependents are notif ied and updated automatically. It is mainly used to implement distributed event handling systems. One example of its usage is : GUI toolkits separate presentational aspect from application data One of the problems of using the observer pattern is that you need to make sure you notify a set of objects that an event has occurred. Another problem is that the set of observing objects can change at runtime. In order to solve these problems, Create an abstract class Subject that maintains a collection of Observer objects When a change occurs in a subject, it notif ies all of the observers in its set.

There is some consequences of these solution. This includes the abstract coupling between subject and Observer as well as the fact that can me unexpected updates because if the data model is changed it needs to be updated. Use the Observer Pattern in the following cases: 1.When the abstraction has 2 aspects with one dependent on the other 2. When the subject doesn't know exactly how many observers it has 3. When the subject should be able to notify its observers without knowing who those observers are

Composite Pattern
The main use of the Composite pattern is to compose objects into a tree to represent partwhole hierarchies where the composition and its parts are treated uniformly. Compose objects into a tree to represent partwhole hierarchies where the composition and its parts are treated uniformly. Lets say Shape is an interface that has a draw method and it has circe and square and composite shape that implement it. Composite shape has a list of many shapes and draw read and remove which add and remove shapes and draws the shapes on the list ! Shape Interface ! Implementing classes ! Composite Shape The Code: / Client */ public class Program { public static void main(String[] args) { // Initialize two circle and a square Circle circle1 = newCircle(); Circle circle2 = newCircle(); Square square1 = newSquare(); // Initialize three composite shapes CompositeShape shapeComp = new CompositeShape(); CompositeShape shapeComp1 = new CompositeShape(); CompositeShape shapeComp2 = new CompositeShape(); // Composes the shapes shapeComp1.add(circle1); shapeComp1.add(circle2); shapeComp2.add(square1); // An instance of compositeShape // appears to the system to be a single // shape ShapeComp.add(shapeComp1); ShapeComp.add(shapeComp2); // Draw the final shape ShapeComp.draw(); } } Create 2 circles and a square 2 composite shapes and adds circles in composite one and square in shape comp2. If we call draw on the final shape all the shapes it consist of will get drawn. Add shape composites in another shapeComp they behave like a shape and draw all the shapes. Use the Composite pattern when: 1. You want to represent partwhole hierarchies of objects. 2. You want clients to be able to ignore the difference between compositions of objects and individual objects. Advantages 1. It makes it easy to add new kinds of components 2. It makes clients simpler, since they do not have to know if they are dealing with a leaf or a composite component One variation of the composite pattern is to declare child management classes in the component class. This variation is more transparent because they can be treated the same At the same time its not safe because they can try to meaningless things tto leaf comonents at run time. They can access therir children to leafs which don't have children.

Decorator Pattern
One that decorates a class or a function. Suppose you want to decorate your room with flowers and patterns. Hire 2 decorators Alice who installs curtains and one that puts flowers in the coffee table, Jenyy Once they decorate the curtains and coffee table someone else comes in and changes the curtains to green.

The Code: Class Room{ . self.curtain = NULL; self.flower = NULL; } //Decorator #1 Alice Class Alice_Curtainsextends Room{ . //initiate, inherit and call AddCurtain() void AddCurtain(){ this.curtain = yellow; } } Room room= new Room(); Print room.curtain > NULL room= new Alice_Curtains(room); Print room.curtain > yellow //Decorator #2 Jenny Class Jenny_Flowersextends Room{ . //initiate, inherit and call AddFlowers () void AddFlowers() { this.flower = red; } } Print room.flower > NULL room= new Jenny_Flowers(room); Print room.flower > red //Decorator #3 Mom Class Momextends Room{ .. //initiate, inherit and call changeCurtain() void changeCurtain() { this.curtain = green; } } Print room.flower > red Print room.curtain > yellow room= new Mom(room); Print room.flower > red Print room.curtain > green The whole story in a single line: Room room= new Mom (new Jenny_Flowers (new Alice_Curtains (new Room())) ); You can always use subclasses instead of decorators. Example: Class DecoRoomextends Room{ { self.curtain = green; self.flower = red; } } Roommyroom = new DecoRoom(); Benefits of using decoraters over subclasses is that they are more dynamic. Some Examples that show situations that subclasses are not a good choice over decorators. Example 1: My brother Michael needs a new room with just red flowers (no curtains). He can just call Jenny: Room room= new Jenny_Flowers (new Room()); We cant do this with subclass DecoRoom, the only way is to implement a new subclass.

Example 2: I want my curtains to be yellow when my mom is on vacation. if (mom = vacation) then room= new Alice_Curtain(room); We cant do this with subclass DecoRoom Example 3: Suppose a software opens a window that can have up to 5 features (horizontalscroll, verticalscroll, boarder, etc.). Any combination of these 5 features are possible, and is determined at runtime. In order to implement this with decorators you only need 5 of them. In order to implement this by making subclasses of the original window class we need: (5 choose 1) + (5 choose 2) + (5 choose 5) = 31 subclasses! In general, decorators are more flexible/dynamic, they can change behaviors of components at runtime, while subclasses can only do that at compile time. For the same reason, a lot of subclasses might be needed because a lot of cases have to be considered. However, if the component is not often subject to behavior changes, subclasses might be a better choice, because it is more concrete, secure. For the same reason subclasses can be better at certain cases when you dont want to change the behaviour. What makes a decoratotr better than just using the add flowers method? you can do that at the parent class but its not a good design. At the same time u dont want to have public get sett method in the parent class.

Discussion in class:
Use patterns as often as possible. They are good and make things more maintanable They are useful the same reason as learning about data structures. You need to use certain pattern so u dont have to reinvent your own way of doing it and when other people look at it they are already familiar about what you are doing. Patterns are the same idea as data structures. There are a lot of patterns out there and a constantly growing number of patterns, Its a standartixation because its one of the more opltimal ways to have some standart so everyone can go by so everyone knows aoutomaticaly that makes some operational as a whole and it it composed of smaller things that are same as the whole. The tricky part is to get others to know your pattern. All can make patterns. If your pattern solves only your problem than no one will care. People will care if there is a common problem and u come up with a solution that you can make a pattern to solve their problem as well.

Design Patterns (Part II)

1. Adapter Pattern
A design pattern that allows classes to work together even though they are not normally compatible to each other. Convert the interface of a class into another interface clients expect. For example, suppose a client specif ies his requirement in an interface, and then to meet the purpose, usually a class is created that implements the required interface and inherits the existing class into the subclasses. This approach creates a class known as the adapter class which translates the client's calls to the existing class methods. A non-software example: a USB to PS/2 converter; if your PC does not have a USB port but you have a USB mouse, plug your USB mouse into the converter and then plug the converter into the PS/2 port on your PC In programming, we have 3 classes a Class PS2Port which has a function that receives a ps2_mouse, Class USB_Mouse that connects to a plug in and the Class Adapter that adapts the USB_Mouse.

Example code: class PS2Port: def __init__(self): pass def receive_ps2_mouse(self, ps2_mouse): return ps2_mouse.confirm_plug_in() class USB_Mouse: def __init__(self): pass def plug_in(self): return 'Now plugged in'

class Adapter: def __init__(self, USB_Mouse): self.adapted_mouse = USB_Mouse

def confirm_plug_in(self): return self.adapted_mouse.plug_in() mouse = USB_Mouse(); port = PS2Port(); adapter = Adapter(mouse); port.receive(adapter); Advantages: It helps the developers to relate incompatible classes such that they may work together. It provides compatibility between classes and increases the transparency. It also provides a pluggable kit, delegates objects, makes the classes reusable and achieves the goal through inheritance or composition.

2. Bridge Pattern
A design pattern that separates the abstraction from its implementation so that the two can vary independently. The difference between Adapter and Bridge is that the Adapter makes two or more classes work together while Bridge acts as a separator between class interface and its

implementation.

Abstraction
defines the abstract interface and maintains the Implementor reference For example Class Shape

RefinedAbstraction
extends the interface defined by Abstraction For example Class Circle extends Shape

Implementor
defines the interface for implementation classes For example Interface DrawingAPI

ConcreteImplementor
implements the Implementor interface For example Class DrawingAPI implements DrawingAPI Advantages: Decoupling abstraction from implementation; the implementation is free to be chosen at runtime (eg. you have a shape interface, but you do not have to pick what kind of shape (Square, Circle, Triangle etc) until runtime) Less classes Extensibility - can add functions in Abstraction without affecting other classes Loosely coupled client codes - if you change implementation in the bridge, there does not have to be any change in the client code Disadvantages:

 Example:

Double Indirection - In the Shape example, RefinedAbstraction needs to point to Abstraction then to Implementor to know which method to implement There is more overhead to be done at runtime

/** "Implementor" */ interface DrawingAPI { public void drawCircle(double x, double y, double radius); } /** "ConcreteImplementor" 1/2 */ class DrawingAPI1 implements DrawingAPI { public void drawCircle(double x, double y, double radius) { System.out.printf("API1.circle at %f:%f radius %f\n", x, y, radius); } } /** "ConcreteImplementor" 2/2 */ class DrawingAPI2 implements DrawingAPI { public void drawCircle(double x, double y, double radius) { System.out.printf("API2.circle at %f:%f radius %f\n", x, y, radius); } } /** "Abstraction" */ interface Shape { public void draw(); // low-level public void resizeByPercentage(double pct); // high-level } /** "Refined Abstraction" */ class CircleShape implements Shape { private double x, y, radius; private DrawingAPI drawingAPI; public CircleShape(double x, double y, double radius, DrawingAPI drawingAPI){ this.x = x; this.y = y; this.radius = radius; this.drawingAPI = drawingAPI; } // low-level i.e. Implementation specif ic public void draw() { drawingAPI.drawCircle(x, y, radius); } // high-level i.e. Abstraction specif ic public void resizeByPercentage(double pct) { radius *= pct; } } /** "Client" */ class BridgePattern { public static void main(String[] args) { Shape[] shapes = new Shape[2]; shapes[0] = new CircleShape(1, 2, 3, new DrawingAPI1()); shapes[1] = new CircleShape(5, 7, 11, new DrawingAPI2()); for (Shape shape : shapes) { shape.resizeByPercentage(2.5); shape.draw(); } } } Known Uses: - Java (Abstract Windowing Toolkit - AWT component)

3. MVC (Model-View-Controller) Pattern

Model - Manage information and inform observer when something changes; handles data, database access, business logic (for example calculating shipping fees) View - Render the Model into a form user can use; basically creates GUI Controller - User input and instructs model to perform actions based on input

MVC Pattern Cycle

1. 2. 3. 4. 5. User Interaction Event captured and handled by controller Controller Communication with model View queries model and render appropriate user interface Wait for step 1 to happen again

Why use MVC Pattern

Goal. High flexibility of code and complexity is reduced Coupling. (low) Modules do not rely on each other much Cohesion. (high) Strong connection of functionalities within a module

Variants on MVC: - MVP: Model View Presenter - usually used for building UIs - MVVM: Model View View-Model - View-Model shows a conceptual view of data including properties and commands - MVA: Model View Adapter - model and view become oblivious of each other; controller is responsible for handling communication Example Code (Ruby on Rails) Controller: class PostsController < ApplicationController def show @post = Post.find(params[:id]) respond_to do |format| format.html # show.html.erb format.xml { render :xml => @post } end end def create @post = Post.new(params[:post]) respond_to do |format| if @post.save format.html { redirect_to(@post, :notice => 'Post was successfully created.') } format.xml { render :xml => @post, :status => :created, :location => @post } else format.html { render :action => "new" } format.xml { render :xml => @post.errors, :status => :unprocessable_entity } end end end end View: <p> <b>Name:</b> <%= @post.name %> </p> <p> <b>Title:</b> <%= @post.title %> </p> <p>

<b>Content:</b> <%= @post.content %> </p> <p> <b>Tags:</b> <%= join_tags(@post) %> </p> <h2>Comments</h2> <%= render :partial => "comments/comment", :collection => @post.comments %> <h2>Add a coment:</h2> <%= render "comments/form" %> <%= link_to 'Edit Post', edit_post_path(@post) %> | <%= link_to 'Back to Posts', posts_path %> | Model: class Post < ActiveRecord::Base has_many :comments end

4. Factory Pattern
A design pattern that allows to develop methods to create Objects. The objects do not necessarily have to be new every time. The constructor does not parse arguments right away A static method is used to produce something. It enables the introduction of a new implementation of an interface while keeping that from the user. The benefit is that the client code is safe and does not break. The main difference of a Factory and a Builder is that a Factory creates an object while the Builder creates an object plus the specif ications of how that object must be instantiated. For example, we may have a static AudioInputDevice that has a function createDevice that accepts, say an AudioStream as parameter. Depending on the parameter we may want to return a new instance of a MICROPHONE, PIANO, etc.

Advantages: Static factories let developers select specif ic implementations of differenct classes for the user instead of the user calling a constructor. Example Code: static AudioInputDevice createDevice(AudioStream in){ switch (deviceType(in)){ case AudioInputDevice.MICROPHONE: return new Microphone(in); break; case AudioInputDevice.PIANO: return new Piano(in); break; . . . } }

5. Strategy Pattern
A design pattern that allows a program to isolate different algorithms into different classes. with each class specifying similarities by implementing a common Interface. i.e, different algorithms can be selected at runtime Can be achieved using function pointers for example Difference between strategy and bridge patterns: the bridge pattern is meant for code structure while the strategy pattern is meant for code behaviour.

Example Code: /* Creates a pathfinder. * @param speed The speed of the pathfinder needed for this object. Speed * needs to be in the set of [0, 99]. * @return a new pathfinder object. If the speed is not in the set [0, 99] * it returns null. */

private static Pathfinder createPathfinder(int speed){ if (speed < 0 || speed > 100) return null; if (speed < 33) return new Tortoise(); if (speed < 66) return new Hare(); else return new Cheetah(); }

Computer-Aided Software Engineering (CASE)

notes by Group Zulu == High-level design to code == What will happen if learn a programming language is not necessary anymore? High-level design -- provides an overview of a solution, platform, system, product, service, or process. Automatic programming means identif ies a type of computer programming in which some mechanism generates a computer program rather than have human programmers write the code. It will be designed in form of UML models or English (high-level design) and code will be generated for Java, Python, C++, C# Examples of Automatic programming: -Design in models: GMF(Java), MyProLang(C#), MyGeneration(VB.NET, C#) -Design in English: Metafor Why Choose High-level design to code? -- 80% of coding is no brain work (Ivar Jacobson), so using high-level design can save time and eliminate bugs introduced by programmers. Pitfalls: -Design in models: Steep learning curve for tools -Design in English: Natural language processing is an extremely difficult AI problem == Code Coverage Tool == -- is a systematic software testing technique used in software testing. -- It describes the degree to which the source code of a program has been tested. -- It is a form of testing that inspects the code directly and is therefore a form of white box testing. White box testing: -- a method of testing software that tests internal structures or workings of an application. -- An internal perspective of the system, as well as programming skills, are required and used to design test cases. -- The tester chooses inputs to exercise paths through the code and determine the appropriate outputs. Black box testing: -- is a method of testing software that tests the functionality of an application. -- Specif ic knowledge of the application's code/internal structure and programming knowledge in general is not required. -- Test cases are built around specif ications and requirements. Coverage Criteria: Function Coverage: invoked every function or procedure Statement Coverage: every node of the program has been executed Decision Coverage: every branch of the program has been executed Condition Coverage: every boolean statement evaluated to both true and false

Other Coverage: e.g. Multiple Condition Coverage, Condition/Decision Coverage Software Code Coverage Tools: Clover (Java), Testwell CTC++ (C, C++), EMMA (Java) == Software Profiling == -- a form of dynamic program analysis -- is the investigation of a program's behavior using information gathered as the program executes. -- Usual purpose of this analysis is to determine which sections of a program to optimize -- techniques: (1) Exhaustive instrumentation, (2) Instrumentation sampling/ temporary instrumentation instrument target program with instructions to collect data Manual, Automatic source level, Compiler assisted, Runtime

(3) Sampling: Timer-based sampling/ Event-based sampling/ Polling-based sampling -- Profiler Implementations: Hardware assisted, Software Profiler -- a performance analysis tool that collects runtime data -- Desired properties: Accuracy, Low overhead (storage, CPU), Portability -- Use: evaluate how well programs will perform on new architectures -- Reason to use: Find performance bottlenecks in program, test new architecture and compilers == Memory Management == -- involves providing ways to allocate portions of memory to programs at their request (allocation) -- freeing it for reuse when no longer needed (deallocation) -- Some languages leave this to the user (C), while some manage memory for the user (Java, C#) -- Garbage Collection: (1) a form of automatic memory management (2) attempts to reclaim garbage, or memory occupied by objects that are no longer in use by the program (3) does not happen immediately -- Memory leaks: consumes memory but is unable to release it back to the operating system -- Tools for finding memory leaks: Valgrind (C, C++), Verbose GC

Refactoring
Brief Overview
What is Code Refactoring?
Simply put, it is cleaning up your code. Or more precisely, "Process of changing a software in such a way that it does not alter the external behaviour of the code yet improves its internal structure".

Why use Code Refactoring?

Improve maintainability Improve readability Improve extensibility Reduce complexity

Maintainability * i.e. organizing methods to fit better in classes, essentially Object Oriented Programming * makes it easier to fix your bugs if everything is easy to maintain and to read, and to add new features Readability * i.e. breaking up large methods into several smaller helper methods * remove methods that don't belong to classes (aren't doing anything useful, or can be done by other functions), and remove bad/misleading comments Extensibility * Makes it easier to add new features to the code * Essentially, provides some flexibility to code things or structure things that might not have existed before Example of why Refactoring is Good:

This illustrates that after refactoring, a lot of the duplicate code was removed, even in programs which were smaller (the Python message board program).

Why NOT use Code Refactoring

When you do not understand the code, so it would break the existing program In long-term projects, code refactoring may not be useful

When to USE Code Refactoring

When it is ugly and unreadable, when it becomes impossible to add new features, code smell (described below)

Code Smell
Code smell is essentially "any symptom in the source code of a program that possibly indicates a deeper problem"

Examples of Code Smell Within Classes

Comments - the comments should be clear, explain the "why" with comments, and remember that comments are written for people Long Method - shorter methods are easier to read, easier to understand and follow along with. Break up larger methods into smaller methods. Long Parameter List - the more parameters a method has, the more complicated it is. Limit the number of parameters, or use an object to combine parameters Duplicated code - exactly as the name implies - duplicate code.

Example of duplicated code: extern int array1[]; extern int array2[]; int sum1 = 0, sum2 = 0; int average1 = 0, average2 = 0; for (int i = 0; i < 4; i++) { sum1 += array1[i]; } average1 = sum1/4; for (int i = 0; i < 4; i++) { sum2 += array2[i]; } average2 = sum2/4; Conditional Complexity - extremely large or monolithic conditional logic blocks. These tend to grow over longer periods of time if you do not maintain your code. Consider using states, or cases instead. Large Class - like large methods, are just simply too big to understand. Try to see if you can break the class down into some smaller classes, or if the class has too many responsibilities (that may be why it's so large).

Type Embedded in Name - if you add types in method names, you will be forced to change the method name if you ever change the type. This is okay for some cases, like toString (which you need and will always be returning a string), but for other cases, you would not want to change the method name if your function changes the type of object returned.

Example of type embedded in name: //bad idea - having return type embedded in method name def getStringName (): return name //better def getName (): return name Uncommunicative Name - if the name of the method does not describe (in brief) what the method is doing, it needs to be renamed. A general rule to follow is that if another developer, after hearing the method name, can summarize what it does, then it is a good name. Otherwise, it is not a good name. Dead Code - Code that isn't being utilized in any way. Delete any code that isn't being used. Temporary Field - If you have a method with a lot of parameters, then make sure they are useful, or if you have an object being passed in and accessed, make sure you are using all/majority of its methods and fields appropriately, not just selectively choosing which fields/methods to take from the object.

Examples of Code Smell Between Classes

Alternative Classes with Different Interfaces - if two classes perform the same basic functions, but are different in how they are called or used, an interface may be useful in this case, to reduce code and complexity Primitive Obsession - don't use huge numbers of primitive data types. If the data type is sufficiently complex, you should write a class for it. Data Class - classes that exist for the purpose of storing data are not useful. They should be both storing and manipulating the data or performing operations on it. Data Clumps - if the same data always seems to show up together, then it should perhaps be clumped together into one class.

Example of data clumps: //bad idea public String getDate(String day, int month, int year) { return (day + " " + Integer.toString(month) + " " + Integer.toString(year)); } //better idea //now this can be reused everywhere with an instance of the Date object by calling the getDate() method as opposed to the other function public class Date { int year, month; String day; public void Date(String day, month, year) { this.day = day; this.month = month; this.year = year; } public String getDate () { return (day + " " + Integer.toString(month) + " " + Integer.toString(year)); } }

Refused Bequest - when you inherit methods from a class, but never use the methods, there is no point to inheriting them Inappropriate Intimacy - when two or more classes keep accessing each others methods, or "private parts". A simple solution is to move either the method or the field to be public, or extract the class. Feature Envy - when a class is using another class' methods/fields completely, and doesn't make use of its own.

Example of feature envy: public class A{ public int mean(int [] list){ int sum = B.getSum(list); int len = B.getLen(list); int mean = sum/len; return mean;

} } Lazy Class - every class should pull its own weight, and do its own work. If it is relying on other classes, or not doing any real work, it should be collapsed or combined with another class.

Example of lazy class: public class Lazy { public boolean False() { return false; } } Solution Sprawl - if you require lots of classes to make something happen/work, like say 5 classes in order to make it work, then you have a solution sprawl and need to look into making your classes do more work.

Refactoring Techniques
Example: //bad public String name; //shouldn't be public //better idea private String name; public String getName() { return name; } public void setName(String nameToSetTo) { name = nametoSetTo; } Example: //Instead of the following: public void show (String s) { s.print(); } public void show (int x) { x.print(); } //You should have: public void show (Object o) { o.print(); } Move method/move field - if code does not make sense or would be better organized in another class, it should be moved. Rename method - correct names for fields/methods. Although they should be concise, they should also be easily readable and understandable. Generalize Type - use general type methods, so you can reuse the same method over and over again. Try to be as abstract as possible. Encapsulate Field - make the field itself private, and provide accessors

Rename Method - a good time to use it:

Pull Up - Whenever you have the same function in all subclasses, and the subclasses all use the function to extract and pull out information for an abstract class (for example). This also reduces duplication of code and centralizes error to one area.

Push Down - If you use a function/procedure only once or so, there is no point in having it in a super class. This wastes memory, and you really only need it in the child class.

Refactoring Tools
Automated Refactoring (manual refactoring is error prone) NetBeans, Eclipse, and IntelliJ for Java offer common refactoring techniques (usually right click, or in the top menu) VisualStudio and ReSharper for .NET No common tools exist for C/C++ however OO languages are better suited for refactoring, there are no appropriate tools for C/C++

Preprocessor directives can cause problems because theyre not legal C code. Pointers AND Cast operations introduce aliasing and make it hard to determine references. If a variable was referenced through pointer arithmetic, a tool would not be able to recognize how you deal with this Example: If conditional of form * sizeof(object) == 15 Refactoring also removes unreferenced variable from class and changes the size of the instance. Refactoring for C/C++ is generally done by hand.

Refactoring in the Real World

Don't Repeat Yourself (DRY) Refactoring saves companies time and money in the long run You are expected to be able to refactor and know how it works in the workforce

Why People Don't Refactor

Developers might not understand how to refactor You might not want to refactor if the benefits are long-term (say, 5 years for example). Nobody wants to exert that pressure now. Refactoring is an overhead activity - unless the client is willing to pay for it, the developer does not care. Developers are paid to write new code that generates money, not fix old code.

Testing
Definition: Any activity aimed at evaluating an attribute or capability or a program or system and determining if it meeta the requirements Blackbox Testing No prior knowledge of the programming, language, etc Used on functional parts of program Advantages: No programming knowledge needed Unbiased Can make test cases early on Disadvantage: cant identify every single test case

Whitebox Testing Used to test structural parts of software Tester has explicit knowledge of internal workings Advantages: Helps with optimizing code Very thorough Does not require GUI Disadvantage: cant tell whether there are missing requirements

Performance Testing Sometimes the specif ication does not mention how optimal the code should be

Performance testing is used to ensure the software does not degrade system performance, running in infinite time or eating up infinite resources Benchmarks used to describe software's performance on low and high-end systems

Reliability Testing Making dependable software is important Making sure things won't fail in an unexpected or catastrophic way Robust testing: does the program crash with exceptional inputs? Stress testing: if the resources are exhausted (high loads of input), how well does the software still work?

Security Testing Areas to cover: Confidentiality: Must not disclose private information Integrity: Making sure information is correct Authentication: Making sure users are who they say they are Availability: Info should be available when needed Authorization: Only allowing access to those with the appropriate privileges Non-repudiation: A time stamp for proof of activity Security taxonomy: A method for security testing

Regression Testing There to see if newly added code breaks older code that previously worked Advantage: test every time you add new code, easy to see where error came from Disadvantage: for bigger companies test itself could take a long while, up to 15min to do the whole test

Other types of Testing There's limits to what a team of testers can do on a large project Massively Multiplayer Online Games Require alpha and beta testing because there many bugs that can't be found without assistance Patching GUIs Are they intuitive? Can you get from start point to destination with relative ease?

Test-Driven Development (TDD) Definition: TDD is a software development process that relies on the repetition of a very short development cycle. Related to the test-first programming concepts of extreme programming that has been recently more general interest in its own rights. It Requires developers to create automated unit tests that define code requirements before writing the code itself, and this is something we have been experiencing since csc108.

There are six steps for the TTD Cycle 1. 2. 3. 4. 5. 6. Add a New Test for your new feature Run Tests and Verify New Test (that would fail now because you havent written the code yet). Write some Code past the test Run Tests to check that they pass Re-factor Code if some tests fail Repeat this process for all the new features you implement in your program.

1. Adding a new test: When implementing a new feature, the test should be written prior to the code itself. To write the tests, the programmer must understand what a feature really is, and know the requirements and specif ication of this feature by looking at user stories and used cases. This will guarantee the programmer will focus first on the requirements and less for coding at this stage.

Run Tests and Verify New Test: All the tests are run to validate that you are testing the right thing and that the new test case is run along with previous written cases to verify proper testing. Knowing the case failed reinforce should give confident to the programmer that right things are being tested and that he is on the right path for the intending case.

3. Writing code: Writing code that will cause the tests to pass. This code will probably not be perfect but still past the test, and this is OK because in the later steps, the programmer will work to improve it. The programmer should focus on passing the test cases and moving on to the next step.

4. Run Test: If the code passes all the tests, the programmer should commit the code that meets the requirements and then move on to the next step of the cycle.

5. Re-factor code: Since optimizing the code is essential in software design, and since the code has passed all the tests, the code should be refactored for optimization without breaking the functionality. Since the programmer already has test cases and the working code, if you break any functionality while working, you can redo the whole thing since the original code works.

6. Repeat this process: When you implement another feature, you basically do these steps again by making new tests and repeating again. The size of these steps Size of steps should always be small between 1to10 steps between test edits. If the new code does not satisfy some of the tests or all the tests fail, it is more preferable to undo the code than spending time on heavy debugging.

Summary of TTD: TDD is basically a confidence builder for programmers and helps them focus on the requirements. A test written and fail which notify the programmer that he needs to meet the feature requirements test. A code is written and revised during some small number of edits to pass the tests, and once it passed, you can commit your work and move on to the next functionality you want to implement till the coding is done.

Testing Frameworks: Most of us are probably familiar with JUnit at least and Nose. Most of these are usually based on one general framework which is called sUnit: This was first implemented as SUnit for Smalltalk which was developed by Kent Beck who is known for extreme programming software development; He is also one of the signatory for the Agile manifesto. The successor of the SUnit is JUnit which was developed by A. Gama, who we know from design patterns. People seem to think that unit testing is a pretty good idea because the code is divided into pretty reasonable chunk of code using your functions. To do unit testing, you make sure that small pieces of code working and then assume that the bigger piece of code or the whole program work. However, this is not very great because when doing human interactions sometimes people dont want to use the program in the same way you specify it or test it and this is where we get expectance testing frame work Expectance testing is used to rig a gap between your client and your actual developers. Expectance testing gives a way of explaining the work to the client in more understandable way.

Expectance testing: You are pretty much looking at a scenario that is formed using user stories in way it is not hard to generate your test from them which is particularly important in case of tester and development because you want to specify your code with your test. Behavior development taking expectance testing in mind Some examples of your scenarios: You are given whens and thens which are your preconditions like models and mockups or a particular list you want to test like a sorted list or a reverse list The whens are the actual behaviors of the function you are trying to test. For example: your are given imaddfacebook.com and when pressing the red flag. you would feel a little more popular and that is your then and you have some sort of outcome you would expect It is difficult to test this in a way that is relevant to machining. Example: If I log in to my facebook and find messages from people I dont know and it is hard to have a Unite Test that says I dont know any of these people by checking your references and things like that. The larger and more complex your system integrated your pieces are, the harder to test small pieces, like databse IO, you need something that is already signif icantly populated that is not always easy to fake. Formal Verif ication Definition: The proof of correctness of an algorithm based on some assumption using formal mathematical proofs. Mostly used by companies that develop hardware Hardware needs to be tested more thoroughly than software Software issues can be patched without too much cost Hardware issues get costly need to be eliminated before production

There are two Formal Verif ication approaches:

Model Checking: Step through every possible outcome to check the model Used for systems with a finite number of states that the model can enter Used to generalize infinite state models Logical Inference: Validation and Verif ication: Also known as Reverse Synthesis Process Answer two questions: Are you building the right thing? (Validation) Are you building it right? (Verif ication)

Validation: Proving the program meets the specif ications of the client/user shows quality assurance usually not automated Example: Client reconstructs a list of user stories and checks their existence in the system.

Verif ication:

Given a Precondition, prove the Postcondition

Postcondition: a condition or predicate that must always be true just after the execution of an operation or code Prove that given a set of specif ication, your program will produce the expected results Commonly used for Loop Invariants Commonly done both automated and manually by a human Coding a unit test computer does the testing Testing that the GUI works human does the testing

Precondition: a condition or predicate that must always be true before the execution of an operation or code

Example: // Precondition: // The parameter a is an array and contains finitely many comparable elements array sort(a) { // Insert favourite sorting algorithm // Possible loop Invariant } // Post condition: // Array a has been sorted in descending order Echo Verif ication: Reverse Synthesis Process Combines both approaches Most commonly used verif ication process 5 step guide to thoroughly proving your program correct:

Model Checking: Step 1, Refining the Specif ications: Reread the specif ication remove all unimplementable features leave behind more theoretical specif ications (infinite sets, runtime complexity...) Implementation details Step 2, Primary Refinement: Pictorial Implementation (make a picture) Annotate the major details of the implementation Step 3, Implementation: Chose the programming language Implement the program from Primary Specif ications (above) Logical Inference: Step 4, Abstract Specif ication: Implementation Specif ication conditions under which your program should produce correct output Listing all the preconditions Step 5, Correctness: Does the program do what you think it does? Prove correctness mathematically (by humans) Automated proofs (by computer) Series of unit tests that are run on command or at a specif ic time

Why use Formal Verif ication:

Exhaustiveness: Calculates run-time efficiencies what's going to happen for large inputs Finds scenarios you may have overlooked Best way to understand your code

Project Management
History
The forefathers of project management are Henry Gantt and Henri Fayol. Henry Gantt was known for his Gantt charts, and Hanri Fayol is known for the creation of his five management functions (which are still used today). In 1996, first post-graduate certif ications for project management were introduced.

Five Functions of Management

Planning Organizing Commanding Co-ordinating Controlling

Gantt Charts
You create visual representation of how your project will go in terms of time with a table listing all the activities, their predecessors, their time estimates (optimal (O), normal(N) and pessimistic(P)), and their expected times (E). The expected time is calculated by the formula: E = (O + 4N + P) / 6. Gantt Table example: Activity A B C Predecessor A B Optimal time(O) 2 3 4 Normal time(N) 4 5 5 Pessimistic time(P) 6 9 7 Expected time (E) 4.00 5.33 5.17

The table is then converted into a chart where each activity will be planned with regards to its expected time.

Process Management
The basic processes are: Initiation: get your project and the requirements from the client Planning or development: create diagrams, backlog, calculate estimated times, weigh costs, consider losses in case if management should be dropped Production or execution: implementation of the project Monitoring or controlling: debugging and testing Closing: go over the project, make sure everything works and nothing is missing

Traditional Approach
Initiation Planning Execution Monitoring Completion

Encouraging good coding

Assigning two people to every part of the project: can be done through pair programming, mentor-trainee method, or the buddy system to assure that everything is readable and there are no obvious mistakes Code review: set up a regular code review with two or more people to make sure that there are no big holes, everything is readable, and the programmer knows that somebody is going to be looking over his/her code Code sign-offs: have a senior developer look over the code before it is committed Publishing good pieces of code: post good code for others to use as an example Making all parts of the code accessible: encourages teamwork and makes sure no one thinks that the code they wrote is their code Using a reward system: encourages people to strive to write good code

Religious issues
Common issues related to each programmers choice: Programming language Indentation style Placing of braces Choice of IDE

Commenting style Spaces vs. tabs

Some programmers are sensitive about their code. This can be dealt by not imposing strict guidelines unless it is necessary.

Dealing with changing requirements

Studies show that an average project experiences about 25% change in requirements during development process, which accounts for 70% to 85% of the rework on a typical project. One way of dealing with changing requirements is to set up a change control procedure that would accept change requests and determine when theyre going to be dealt with and how. This way, the programmers dont have to deal with constant change requests and the client would be certain that their request will be considered. Even though easy changes are very tempting early in the project, they might affect the project by pushing it back slightly or have ripple effects that would change other parts of the project. This can be dealt with by setting up a specif ic time and going through all requests since the last period of time and deciding which ones to implement. It can be difficult to estimate the cost of a small change because you have to consider ripple effects that might change the whole project. A high volume of change requests suggests that the process wasnt designed very well to support all these changes, or that the client isnt sure what exactly does he want.

Timing
From a study: the average large software project is one year late and 100% over budget. Programmers are notoriously bad at estimating the time required to complete a project. Hofstadlers Law: it always takes longer than you expect, even when you take into account Hofstadlers Law. Constructing a time estimate that is as accurate as possible is the basis of good project management. There is a number of ways of estimating the time: Specialized estimating software External estimation experts Estimate individual pieces and add them together Have each person estimate their own task and add them together Use your experience from previous projects

Time estimation basics: Establish objectives Plan time to actually make your estimates Break down software requirements Estimate everything at a low level Use several different techniques to estimate time and compare results Re-estimate periodically

Measuring your projects progress gives you useful information and points out anomalies and problematic areas. Things that are useful to measure: Size: lines of code, number of classes Overall quality: number of defects, mean time between failures Productivity: work hours spent, dollars spent

What you choose to measure affects peoples productivity. What to do when a project falls behind: Dont try to catch up later Dont expand your team Reduce the scope of your project See if you can drop minor requirements Produce cheaper code

Code metrics / software metrics

Definition: It is a measure of some property of a piece of software or its specif ications (Rules for quantifying a written program) Metrics have become an integral part of the software development cycle.

Common Software Metrics: Code coverage

A measure used in software testing. It describes the degree to which the source code of a program has been tested. It was among the first methods invented for systematic software testing.

Basic coverage criteria:

Function, Statement, Decision/Branch, Condition, Decision + Condition Coverage Given a percentage of code coverage might not be correct as it is relative to each criteria. All criteria coverage need to be tested.

Purpose:
Allows developers to look for parts of a system that are rarely or never accessed under normal conditions combined with other code coverage methods, the aim is to develop a rigorous testing.

Cohesion
Cohesion describes how focused a piece of software is. A highly-cohesive system is one in which all procedures in a given module work together towards some end goal.

Types
Coincidental (worst), function (best) Coincidental grouped arbitrary. Just because they are in the same function, nothing to do with each other. Functional contribute to each other, all work together and work on the same thing.

High cohesion improves readability and maintainability of a program. Low cohesion increases flexibility of a program to some extent. The degree to which each program module relies on each one of the other modules is usually contrasted with cohesion.

Coupling
The degree to which modules are dependent on each other Content coupling (highest) Message coupling(lowest)

Disadvantages:
A change in a module forces a ripple effect of changes. Hard to reuse, not for multipurpose.

Advantages:
A change in one module does not force a ripple effect. Easier to reuse, good for multipurpose programs.

Program Load time

Measures the amount of time for the program to load before the user can interact with it.

Disadvantages:
Inconsistency in measurement Misleading at times

Comment density
Measures how many meaningful comments there are per each logical line of code. 1 comment per 5 lines of code industry standard.

Problems with this:

What is meaningful is what you write in the comments not how many you have.

Source lines of code(SLOC)

A software metric used to measure the size of a software program by counting the number of lines in the text of the program's source code.

Physical SLOC
Measure of actual number of lines in source codes.

Logical SLOC
Measure amount of statements, i.e for, if and so on.

Advantages
Measures the size of software.

Disadvantages:
Coding phase usually accounts for only 35% of the overall effort. Software is often developed in more than one language.

Errors per line of code

Average is 15-50 errors per 1000 lines of delivered code.

Execution time
Time during which a program is running(executing) Closely linked to this most basic sense is the state of the entire system on which the program is running, which affects the program's execution and which varies between instances.

Summary
You can't control what you can't measure. Code/Software metrics give a way for measuring code Using these measurements is important in building efficient software

Security (Notes by Team Echo)

What is Security
There are 4 main areas to focus on (CIAA):

Confidentiality Preventing unauthorized release of info Integrity Preventing unauthorized modif ication Authentication

Verifying identity

Availability Service being provided to only authorized users

Web Security Problems

Application Vulnerability
Passwords Always set the input type to "password" in your HTML. This will mask the password. Otherwise, passwords will be displayed to anyone viewing the page Example:

<input name=password type=text value=haxxor/> Fix: <input name=password type=password value=haxxor/> Never use GET methods for submitting passwords, use POST. Otherwise, the user's password will be shown in the address bar when they submit the page

<form method="get"> Fix: <form method="post"> Never store passwords in plain text in the database. If they are ever leaked and a user has the same password for another site, that site's account will be compromised too Store only passwords hashed with things like MD5 or SHA Never store hashed passwords in the database without salting them. This is almost as bad as leaving them in plain text. Passwords can be looked up in reverse by their hashes using rainbow tables. Use salted passwords Add some secret text to passwords before hashing so that they can't be easily looked up

SQL injection
Malicious input that contains SQL Caused by bad input checking When a user submits input that is inserted into an SQL string between quotes, they can add their own quotes to break out and add their own SQL commands. Example:

SELECT * FROM Users WHERE UserName="$username" AND Password="$password" User submits: admin"; -- as their username. Query becomes: SELECT * FROM Users WHERE UserName="admin"; --" AND Password="$password" They are given admin access because there password check is now commented out Fixes:

Escape quotes and special characters using mysql_real_esape_string() in PHP Escape any input that comes from the user's side When in doubt, escape Use a web framework Use prepared statements (best option)

Unicode attack(GBK) 0x5c -> / 0xbf5c -> valid multi-byte Chinese character. By injecting this xbf27, addslashes() will modify xbf27 to become 0xbf5c27, which is a valid multi-byte character (-xbf5c) and is followed by an non-escaped inverted comma. Fix: mysql_real_escape_string()

Source code leaks

Can be intentional (from malicious employees) or because of security problems Can leak things like database credentials that are saved in Source Code

Use firewalls to prevent these leaks Set up proper file permission to restirct access

API keys
Only allow for internal IPs

CSRF
Cross-site request forgery Include things like click attacks and session riding Unauthorized commands from users that a website trusts Malicious exploit of a website where unauthorized commands are transmitted from a user that a website trusts Bad website sends browser request to good web site, using crednetial of an innocent victim Leverage user session at server to do something harmful

XSS
Cross-site scripting Malicious URL that appears legit Exploits the trust that a site has Can be used to steal info from honest websites

General code injection: Enable attacker to execute arbitrary code on the server
When you use the eval() or system() functions in PHP Users may be able to run their own code if you use user input in the call Fix: don't use these functions

Coding Security Problems

Buffer overflows
Overrun bounds of buffer and write or read adjacent memory Each function call in a program adds a new stack frame that stores hardware registers for later use. When returning from a call, computer pops a frame off of the stack stack and uses it as return address to know where the program goes back to. Sometimes, you can overwrite return address to jump to your own code You can also overwrite adjacent variable to change program flow or just crash Example:

#include <string.h> void sloppy(char *slop) { char c[12]; strcpy(clop, c); } int main(int argc, char **argv) { sloppy(argv[0]); return 0; } Attacker can give the above program a string that is longer than 12 and has a return address at the end. This return address can point to malicious code to execute Return to libc attacks Exploit address points to libc (because its always linked) Fill rest of space with args to the function Requires guessing or instructions to read the memory location There can be stack or heap allocated buffer overflows (heaps have no return address) Heap: overwriting the memory meta data from malloc to run your code Problems: trusting user data Eg: giving invalid heights for image. Overflow these variables in a specially crafted image file so that malloc allocates less memory than needed. You can then store code in the extra space Protections: non-executable stack (marked as data only) address space randomization (makes it much hard to craft a buffer overflow because it changes every time) Use safe libraries: strncpy and specify size of buffer Canaries

Used by GCC stack-smash protector Put small int at end of every buffer Check to see if it was overwritten, if it was, there was an overflow so you should just terminate Run code through fuzzer Runs app with random inputs, should find an overflow Code reviews Check for off-by-ones Need to calculate bounds correctly Very common in C, C++. They were discovered in 1988 with the Morris worm, which exploited the finger service Famous examples: Code Red Worm (2001) IIS hole SQL slammer (2003) MSSQL server Twilight hack Used for modding Wii Iphone, PS3 Heap based overflow for jailbreaking Similar problems with dangling pointers. This is when you free objects but dont clear the pointers Can be used to exec code

Format string vulnerabilities

Write into inappropriate locations in memory, allowing code execution Crash a program by executing harmful code Use %s and %x format tokens, to print data from the stack or other locations in memory. Write in inappropriate locations using token %n

Integer overflows
Occurs when an arithmetic operation attempts to create a numeric value that is larger than can be represented within the available storage space.

Code/command injection
When attacker inserts own code

Other security problems

Password reuse Social engineering

Security Development Lifecycle (SDL)

Building with security in mind

If only the developers had built these applications with security in mind, we wouldnt have these security problems? We built to spec, give us security specif ications and we will make it happen!
Have a security team that looks at the standard development lifecycle and comes up with security specif ic artifacts to fill in the existing gaps **Standard Software Development** **Security-Specif ic Artifact** Misuse cases Malicious point of view Things user should not be allowed to do **Phase/Activity**

Use cases **Analysis**

Functional & Non-functional requirements Glossary Object Model Threat Model **Design** Design Patterns Data classif ication Security Integration Unit Tests Unit hacks **Coding** Code Development Counter measure and detection development Build and configuration Security baseline **Deployment** Optional Processes Response processes Integration to overall security architecture

Intellectual Property
Intellectual Property (IP) Defined:
refers to a number of distinct types of creations for which property rights are recognized owners are granted the exclusive rights to their assets

Roles of Intellectual Property

Establishes a right and identif ies ownership of a certain intellectual property. Enhances the value of a business IP assets accrue to their owners through its business development and strategies IP instills trust to the consumers it markets

Subject Matters Protected by IP

Literary, artistic and scientif ic works Performances of performing artists Inventions/Scientif ic Discoveries Industrial Designs Trademarks

Two Main Branches of IP

Industrial Property
related on the invention side protects "ideas" patents, industrial designs, trademarks

Copyright ("the right to copy")

related on the literary side protects "form of expression" of ideas books, paintings, computer programs, electronic databases

Rights Protected
Reproduction in various forms Distribution of copies Translation into other languages Adaptation

Patent
Definition
A document that describes an invention protects an invention from exploitation

Issued by a government office Application requires approval Lasts for a limited time (usually 20 years)

What is an invention?
A solution to a specific problem in the field of technology: a product or a process Must be: Industrially applicable Novel Non-obvious (an expert given the appropriate tools cannot invent this themselves)

Things that CANNOT be patented:

Discoveries of materials or substances already existing in nature Scientif ic theories or mathematical methods Plants and animals other than microorganisms Biological processes vital to the production of plants and animals Methods for treatments of humans or animals Schemes, rules, or methods, purely mental acts or playing games Anything that contravenes public safety or morality

Filing a Patent Application

Provide an overview of how to solve the problem: Descriptions Diagrams

A person skilled in the trade must be able to re-create Often exceeds $30,000 (+annuities) and can take several years "Provisional Patents" only last 1 year

Patent Office
Verifies and approves applications Search (check that it satisfies the criteria for a patent) Certif icate of Grant

Makes patent documents accessible Official Gazette

Handles disputes Can last years

Enforcement
Responsibility of the patent holder Must first pursue primary infringer Steps of enforcement: Provide notice of infringement Negotiate a license Litigate (loss implies invalidation of patent)

Types of Infringement
obvious deceptive/inspirational accidental/paranoid

Establishing Infringement
Prove the following: 1. 2. 3. 4. someone did something they are not allowed to (prohibited act) they did this after you patented and published your idea it happened in the same country what they did actually relates to your patent

1. Prohibited Acts Doing any of the following: making (manufacturing), using, selling, or importing the patented product (or products directly obtained through a patented process)

is prohibited without permission from patent owner. Using and selling are prohibited even if you have permission. Exceptions to Prohibited Acts Exceptions to making a product: product made only for scientif ic research made by 3rd party before patent was filed being made for public interest or under compulsory license

Exceptions for using a product: used only for scientif ic research the patent owner put it up for sale use occurs in a vehicle 3rd party who has special permission to keep making the product is using it used under compulsory license or for public interest (government gave permission)

2. After Patent & 3. Same Country it does not make sense to accuse someone of infringing something that no one knows about patents do not generally extend beyond country borders

4. Within Scope claims of patents must be broken down into elements and checked against elements in the infringement

if all the elements in the claim are in the elements of infringement, then it is an infringement for a process, if the result is the same but the process "tweaked" it is still infringement doctrine of equivalents (substituting elements for equivalent ones does not work)

Remedies for Infringement

civil sanctions
always available for example, fees or injunction avoid fees by proving you did not know about patent injunction: an order to stop infringing

criminal sanctions
only available when it was intentional infringement depends on law in country

Exploitation of Patent: Selling

do research on the market will the product sell? test marketing sell product or license product to a company that can manufacture coolness

Compulsory Licenses
Voluntary vs. Compulsory
voluntary licenses are granted by the patent owner compulsory licenses ("non-voluntary") are given by the government against will of the patent owner prevent abuse of patent for the "greater good"

Preventing Abuse of Patent

nonworking of patent procedural safeguards & compensation revoking patent because of abuse

Nonworking of Patent
working: making of product or use of the process either by patent owner or licensee

useful without working: inspiration enters public domain after expiration

compulsory vs. optional working government wants transfer of technology

Compensation & Revocation of Patent

owner gets compensated - licensing fees license can be revoked if there is no longer a reason to keep it if compulsory license was not enough to prevent abuse, the patent itself can be revoked

License for Public Interest

for private parties

dependent & dominant patents avoid abuse with patenting trif ling inventions dominant patent may get equal treatment (compulsory license on dependent patent)

for the government national defense, economy, or health e.g. some medical equipment during an epidemic

Disadvantages to Compulsory Licenses

absence of atmosphere of cooperation counter intuitive to the intended transfer of technology economic feasibility - nature of the market

TRIPS Agreement
allows exploitation of patent against will of owner many conditions under which this is allowed

Utility Models
these are inventions in the mechanical field different in two aspects inventive step/technological progress is smaller term of protection is shorter

must be distinguished from other patents