Show Menu
Cheatography

Intro

What is software engine­ering?
Engineer = capable of designing a system; Programmer = hired to produce code; Developer = design and architect software + documents; Software engineer = thinks of the end product, bridges the gap between customers and progra­mmers
Requir­ements Engine­ering
Domain Analysis; Problem Defini­tion; Requir­ements Gathering; Requir­ements Analysis; Requir­ements Specif­ication
Requir­ements Engine­ering Details
Design = User Interface Design, Define Subsys­tems; Modeling = Use Cases, Structural (Formal) Modelling, Dynamic Behavi­oural Modelling
Quality Assurance
Review and Inspec­tion; Testing; Deploy­ment; Config­uration Manage­ment; Process Management = Cost Estima­tion, Planning

Increm­ental vs Iterative

Increm­ental
Iterative
1. The requir­ements are divided into different builds
1. Does not start with a full specif­ication
2. Needs a clear and complete definition of the whole system from the start
2. Building and improving the product step by step
3. Customers can respond to each build (but a build may not represent the whole system)
3. We can get reliable user feedback
4. Increm­ental fundam­entally means add onto and helps you to improve your process
4. Good for big projects
 
5. Only major reqs. can be defined, details may evolve over time
 
6. Iterative fundam­entally means redo and helps you to improve you product

Story Cards

Title = Should be a verb descri­ption (Ex. View a product location)
Goal = "As a {type of user}, I want to {perform some action} so that I can {achieve some goal}"

Story Maps

Story Maps add narrative structure to a backlog
-Top Level: Main features. Also know as a project backbone
-Second Level: important tasks or related stories. Also known as a walking skeleton.
-Addit­ional tasks are added to flesh out intera­ctions

Protot­yping

Types of Protot­ypes:
Throwaway = Example is a paper one. Will be used only for evalua­tion; Increm­ental = created a separate compon­ents; Evolut­ionary = refined to become actual product
Prototype Fidelity:
Low = Omit details (Rough, no code, easy to trash) - Paper, Storyb­oard, Wizard of OZ (evalu­ation) High = Looks like a polished product (looks of product, comment on aesthe­tics, GUI powerpoint etc are used)
Protot­yping can help answer:
- Crowded UI, Knobs versu slider for contro­lling volume, Navigation = Transp­arent or solid menu?

White Box/Black Box Testing

White = AKA glass box, struct­ural; Tester know the source code and can debug at runtime = Develo­per's perspe­ctive
Unit Testing = Do discrete parts of my system work as expected?
- Does an individual method work as expected?
- Necessary calls to other methods should be mocked out where possible
-Always white box
Black = Tester gives inputs and observe outputs (No code, only focus on reqs., interacts with UI only) = User's perspe­ctive
Acceptance Testing = Is the system working from the customer's perspe­­ctive? (AKA. System testing)
- Interacts with system through GUI
- Focused in feature
Usually black box
White = Did we build the system right?
Black = Did we build the right system?

Agile vs TDD

TDD = focused on how code gets written (for work cycles of indivi­duals or small groups of developers exclus­ively)
Agile = Overall develo­pment process (focuses on project management and groups of develo­pers, as opposed to specif­ically how a given developer writes code)

Polymo­rphism

A property of OO software by which an abstract operation may be performed in different ways, typically in different classes.

Inheri­tance

Implicit possession by a subclass of features defined in a subclass. Features include variables and methods

Abstract Classes and Abstract Operations

Abstract Operations
No method for that operation exists in the class
Abstract Class
Cannot have any instances
- A class that has one or more abstract more abstract methods must be declared abstract.
- Any class, except a leaf class, can be declared abstract
- Label with <ab­str­act>

Sturctural Modelling

Genera­liz­ation: Specia­lizing a superclass into subcla­sses. Avoid unnece­ssary genera­liz­ations
Depend­ency: Used for extremely weak relati­­on­ships between classes. Ex. A class makes use of a library
Aggreg­ation: Represents "­par­t-w­hol­e" relati­ons­hips. The whole side is called the aggregate. Aggreg­ations are read as "is part of"
Compos­ition: Are strong forms of aggreg­ation. If the aggregate is destroyed, then the parts are also destroyed.
Aggreg­ation = An associ­ation is an aggreg­ation if: the parts 'are part of' the aggregate. The aggregate 'is composed of' the parts. When something owns or controls the aggregate, then they also own and control the parts

Evolva­bility

"The ability to be evolve­d" - to adapt in response to change in its enviro­nment, requir­ement and techno­logies that may have impact on software structural and/or functional enhanc­ements, while taking archit­ectural integrity into consid­eration
Potential to respond to the pressure to change with minimal modifi­cations
Ex. Bug fixes, enhanc­ements, refact­oring, porting
Complexity inherently increases unless work is done to maintain or reduce it

Design Principe 1: Divide and Conquer

Doing something big is normally harder than breaking things up
Separate people can work on each part.
An individual software engineer can specialize
Easier to unders­tand, individual small components
Parts can be replaced or changed without replacing or changing other parts
Ways of dividing: distri­buted systems = clients and servers; systems = subsys­tems; subsystem = one or more packages; package = classes; class = methods

Design Principle 3: Reduce coupling

Occurs when there are interd­epe­nde­ncies between one module and another
When interd­epe­nde­ncies exist, changes in one place will require changes somewhere else
Network of interd­epe­nde­ncies makes it hard to see at a glance how some components work
Coupling implies that if you want to reuse one module, you have import the coupled ones too
Types (high coupling to low): - Content: one module to another - Common: two modules share global data, - External : two modules share data format, protocol, - Control - one module controls the flow of another through the argument it passes, - Stamp: Modules share a data structure but each only use a part of it, - Data: modules share data (through parameter passing), - Message: commun­ication between modules via message passing

Adapter

Context = Building an inheri­tance hierarchy and want to incorp­orate it into an existing class; the reused class is also often already part of its own inheri­tance heirarchy
Motivation = how to obtain the power of polymo­rphism when reusing a class whose methods have the same function but not the same signature as the other methods in the hierarchy?
Pros = allows you to reuse code that doesn't quite match the method signature you were expecting and you can't modify, decouples clients from internal structure
Cons = changes the interfaces to the functi­onality you want to use, overuse allows for many redundant classes

Singleton

Intent = ensure a class only has one instance and provides a global point of access to it
Motivation = It's important for some classes to have exactly one instance. We want to use a single log object to keep track of when multiple threads are taking certain actions and it's important that the timing is shown correctly
Pros = Ensures only one instance is created
Cons = Better ways of doing this, usually used wrong and is dangerous (security)

Observer

Context = When an associ­ation is created between two classes, the code for the class becomes insepa­rable, reuse of one class means reuse of the other
Motivation = how do you reduce the interc­onn­ection between classes, especially between classes that belong to different modules or subsys­tems?
Antipa­tterns = Connect an observer directly to an observable so that both have reference to each other, - Make the observes subclasses of the observable
Pros = Limits the amount of inform­ation accessed by different classes, ensures that events are handled
Cons = Many modern progra­mming languages have a better, built in event system

Software Archit­ecture

Process of designing the global organi­zation of a software system including:
- Dividing software into subsystems - Deciding how these will interact - Determ­ining their interf­aces: the archit­ecture is the core of the design so all software engineers must understand it. Archit­ecture will often constrain the overall effici­ency, reusab­ility and mainta­ina­bility of the system
Import­ance: To enable everyone to better understand the system, To allow people to work on individual pieces of the system in isolation, prepare for extension of the system, facilitate reuse and reusab­ility
Archit­ecture in different views:
- Logical breakdown into subsys­tems, - Interfaces among the subsys­tems, - Dynamics of the intera­ction among components at run time, - Data will be shared among subsys­tems, - Components will exist at run time and the machines or devices on which they will be located, -
Ensuring mainta­ina­bility and reliab­ility = archit­ectural model is stable
- Stable = means new features can be easily added with only small changes to the archit­ecture

Developing an archit­ectural model

Start by sketching an outline:
- Based on the principal reqs. and use cases
- Determine the main components that will be needed
- Chose among the various archit­ectural patterns
- Sugges­tion: Have several teams indepe­ndently develop a first draft of the archi. and merge together the best ideas.
Refine the archit­ecture:
- Identify the mains ways in which the components will interact and the interfaces between them
- Decide how each piece of data and functi­onality will be distri­buted among the various components
- Determine if you can re-use an existing framework, if you can build a framework.
*Mature the archit­ecture
- All UML diagrams = useful for describing aspects of the archi. model
Archit­ecture using UML diagrams particular = Package, subsystem, component, deployment

Model View Controller (MVC)

Intent = an archit­ectural pattern used to help separate the user interface layer from other parts of the system
Motivation = I have a program which interacts with advanced user (through command line) and novice users (through a GUI)
Model = Manages behaviour data, responds to requests about its state (view), responds to state change commands (contr­oller)
View - Manages display of inform­ation
Controller = Interprets user input, changes model and view
Pros = Separation of concerns, increased usability, readab­ility, reusab­ility and testab­ility
Cons = none worth mentioning

Refact­oring

Improving the design of an already written code
The process of changing a software system while not altering the external behaviour of the code
A discip­lined way to clean up code that minimize the introd­uction of bugs
Code Smell = surface indication that corres­ponds to a deeper problem in the system (Dupli­cated code, Feature Envy, Middle Man, Temporary Fields)
Refact­oring Techniques = Extract method, Move method, Pull Up method, Remove middle man, Extract Class, Inline = put body in caller's method and remove the self method
Duplicated code (same expression in two methods of same class or subcla­sse­s/s­imilar code/does same thing, different algorithm) = Extract method, Pull up method­/field
Feature Envy (likes other classes than it's own) = Move method, Extract method
Middle man (delegates task to others) = Remove middle man
Temp. field (empty unless needed) = Extract class

Requir­ements Activities

Eliciting Requir­ements; Modeling and Analyzing Requir­ements; Commun­icating Requir­ements; Agreeing Requir­ements; Evolving Requir­ements
Elicit­ation = Surveys, analysing existing documents, brains­tor­ming, model driven techni­ques, observ­ation or card sorting
Modelling = Data, Enterp­rise, Behavi­oural, Domain or non-fu­nct­ional reqs.
Commun­icating = Effective commun­ication among different stakeh­olders
Agreeing = Verifi­cation and valida­tion, requir­ement conflicts, requir­ement risks, stakeh­older conflicts
Evolving = Managing change, adding reqs, reqs. scrubbing, fixing errors, managing docume­ntation

Overriding

1. SubClassA inherits a method M from A
2. SubClassA implements method M' such that the signatures of M and M' are indist­igu­ishable
3. M' is said to override M

Dependency vs. Associ­ation

Depend­encies only involve using other classes
Associ­ations involve mainta­ining references to other classes

Aggreg­ation vs Compos­ition

Aggregate parts continue to exist if the aggreg­ation is destoryed and can be used in multiple aggreg­ations
Composite parts are specific to their compos­ition and will be destroyed with the compos­ition

Sequence vs. Commun­ication

Sequence = good for explicit ordering of intera­ctions (Inter­action model for use case = use case make time ordering explicit)
Commun­ication = Adding details to class diagrams (validates a class diagram and derives an intera­ction from a class diagram)
Adds detail to messages (Commu­nic­ation has less space)

Mainta­ina­bility vs. Evolva­bility

Mainta­ina­bility = actual effort required to locate and fix a fault in the program within its operating enviro­nment
Evolva­bility = potential to respond

Evolva­bility Charct­eri­stics

Integrity
Capability of the software system to maintain archit­ectural coherence while accomm­odating changes
Change­ability
Capability of the system to enable a specified modifi­cation to be implem­ented.
Portab­ility
Capability of the software system to be transf­erred from one enviro­nment to another
Extens­ibility
Capability of the software system to enable the implem­ent­ation of extensions to expand or enhance the system (new capabi­lities and features) with minimal impact to the existing systems
Testab­ility
Capability of the software system to enable modified software to be validated

Design Patterns

The recurring aspects of designs
Pattern = outline of a reusable solution to a general solution encoun­tered in a particular context
Name = unique name for each pattern to ease commun­ication
Intent = Descri­ption of the goal of the pattern
Motivation = short scenario illust­rating the context in which the pattern can be used
Structure = Class and/or intera­ction diagrams graphi­cally illust­rating the solution
Conseq­uences = Descri­ption of the side-e­ffects and results of the pattern

Concurrent Engine­ering

Divide and Conquer
Teams work on separate compon­ents: Follow their own approach
Main Risk: Components don't integrate properly
Design break each other

Common Agile Practice

Refact­oring: Increm­entally improving the code
Sustai­nable Pace: No overtime, people work when rested
No sustai­nable pace because:
-Teams do not have an option to make their own decision
-Alloc­ating people on multiple projects
-Team's inability to say "­No"

Agile vs. Spiral

Agile
Spiral
Iterations are shorter (1 to 4 weeks)
Iterations are longer (4 to 6 months)
Not good for low rates of requir­ements change (cost of collab­ora­tion)
Suitable for large scale develo­pment (due to risk analysis)
Is good for low-risk and less critical systems
More emphasis on docume­ntation and process
Both are increm­ental and iterative

Parts of a Use Case

Name = What is this use case about?
Needs to be descri­ptive so people can use it. The most important part
Actors = Who is going to use this use case?
Focus on types of people
Postco­ndi­tions = What is the result of this intera­ction
Focus on what has been accomp­lished
Name: Add announ­cement to a single course
Actor: Instru­ctors, TAs
Postco­ndi­tions: New announ­cement is added to main Blackboard page for all users. New announ­cement is emailed to student users.

Integr­ation Testing

Do various parts of the system work together?
- Do subsys­tem­s/c­las­ses­/me­thods work as expected with other subsys­tem­s/c­las­ses­/me­thods in the system?
-Do parts of my system work with external depend­encies? (database, web services)
-Usually white box

TDD

Specif­ication and not validation (one view), Is a progra­mming technique (another view), Is a way of managing fear during progra­mming, Enables you to take small steps when writing software
Writing the test beforehand makes developers think from a user's perspe­ctive when coding leading to a usable API

Static vs Dynamic Testing

Static
Dynamic
Validation
Verifi­cation
Objective = Finding errors in early stages of the develo­pment cycle
Objective = Checks the functional behaviour of the system
Check that the software product meets the customer's actual needs
Whether the system is well-e­ngi­neered? Error free?
Are we building the product right?
Are we building the right product?
Dynamic
Static
Activities = Reviews, Walkth­roughs, Inspection
Testing - The product meets the user's needs = the product fulfills its intended use
The product is built according to the reqs.
Checking whether the software is of high quality will not ensure that the system is useful. So Trust but verify, verify but also validate.

Testing Practices

Explor­atory Testing
Simult­ane­ously learning about the software under test while designing and executing tests
 
Uses feedback from the last test to inform the next
Brute Force Testing
Testing using every possible input parameters
Equiva­lence Classes
Divide possible inputs into equiva­lence classes based on how the system should react to them
 
Input in same equiva­lence class = same system code trigger
 
Only one test per equiva­lence class
 
Testers require knowledge: how system works (inter­nally and in detail), how to create input to trigger all code paths
Explor­atory = Is a core testing practice for Agile teams
Brute = impossible as you cannot test the whole system
- There is always a limited time for testing and need to focus on testing inputs that will give us the most return on investment

Race Conditions

A race occurs when two threads are using the same resources and the order of operations is important
Critical races can be prevented by locking data so they cannot be accessed by other threads
Ex. A keyword like synchr­onized
Testing Strategies
- Hard to test critical races
- Use mocking to control the order

Why Object Orient­ation?

OO is primarily a software progra­mming paradigm
OO systems make use of abstra­ction in order to help make software less complex
OO systems combine procedural and data abstra­ctions = organizing procedural abstra­ctions in the context of data abstra­ctions
OO paradigm is an approach which all comput­ations (abstr­act­ions) are performed in the context of objects.
OO analysis = which objects are more important for the users (no progra­mming consid­era­tion)
Procedural = The entire system in organized into a set of proced­ures. One main procedure calls the others. (Performs calcul­ations with simple data)

Data = Idea to group together the pieces of data that describe some entity, so that progra­mmers can manipulate the data as a unit

Instance Variables

Attribute
A simple piece of data used to represent the properties of an object
Associ­ation
Represents the relati­onship between instances of one class and instances of another
Static Variable
A variable whose value is shared by all instances of a class
Method in OO
Procedure, function or routine in other progra­mming paradogms
Methods
Procedural abstra­ctions used to implement the behaviour of a class
Operation
Used to discuss and specify a type of behaviour, indepe­ndently of any code the implements that behaviour (higher level abstra­ction)

Interface

Has neither instance variables nor concrete methods.
It is a named list of abstract operations
Every single method declared in an Interface will have to be implem­ented in the subclass

UML Diagrams

Intera­ction Diagrams: A set of diagrams to model the dynamic aspects of the system. To visualize how the system runs. Often built from a use case and class diagram to illustrate how a set of objects accomplish the required intera­ctions with an actor.
Sequence Diagrams: An intera­ction diagram that focuses on the sequence of messages exchanged by a set of objects performing a certain task
Commun­ication Diagrams: Emphasize how objects collab­orate to realize an intera­ction
State Diagrams At any given point in time, the system is in precisely one state and will remain in the state until an event occurs to change state. Is a directed graph, nodes are states, edges are transi­tions. Have timeouts to automa­tically change states
Intera­ction Diagrams Show (Inter­action) = the steps of the use case, the steps of a piece of functi­ona­lity. Composed of instances of classes, actors and messages.
Sequence Diagrams: Can represent condit­ional logic and loops and show explicit destru­ction of objects.
Commun­ication Diagram: Annota­tions of object diagrams. Shows link between objects that commun­icate

UML Modelling

UML (Unified Modelling Language) = graphical language for modelling OO software. 1980s - 1990s = first OO develo­pment processes
Types of UML diagrams = Class, objects, intera­ction, use case, state, activity, component and deployment
Class and object = describe class + methods, relati­onship between classes
Intera­ction = How object interact, how system behaves
Use Case = what users can do, feature are related
State + activity = how system behaves internally
Component + Deployment = how the various components of the system are arranged logically and physically
Main symbols = Classes, Associ­ations, Attrib­utes, Operat­ions, Genera­liz­ations (groups classes into inheri­tance hierar­chies)
- Associ­ations can be labelled to make explicit associ­ations (are bi-dir­ect­ional by default, can add an arrow) = many to one, many to many, one to one/one to itself (one to one can sometimes be unnece­ssary, look carefu­lly!)

Design Principle 2: Increase Cohesion

Subsystem or module has high cohesion when related things are kept together and everything else out
Measures the organi­zation of the system, makes it easier to understand and change
Types = functi­onal, layer, commun­ica­tional, sequen­tial, proced­ural, temporal, utility
Functional = code that computes a particular results is kept together (easy read, replac­eable and reused)
Procedural = keeps procedures together (does not necess­arily provide input to the next)
Functional = updating a database, creating a new file or intera­ction with a user is not functi­onally cohesive
Procedural = Each individual should have high cohesion in addition to organizing code in objects

Facade

Intent = to simplify the interface to a compli­cated subsystem
Motivation = I have several parts of a subsystem that is getting quite compli­cated and I would like to simplify the process for using the subsystem.
Pros = increases readab­ility and testab­ility, reduces coupling
Cons = if your subsystem changes, your facade will need to be updated as well

Requir­ements

Problem
General Goals (Sched­uling a room for a course)
Requir­ement
All of the things that a system needs to do!; Things you system should (or should not) do; Features your system must provide; Things your users will expect
Functional Requir­ements
Inputs the system should accept; Outputs the system should produce; Data the system should store that other systems might use; Comput­ations the system should perform (Not algori­thms); Timing and sync. of the above (Not response time but the ordering of events)
Functional Requir­ements: Could relate to intera­ctions with a person or with another system

Functional vs. Non-fu­nct­ional

Functional
What is the system doing? For example: Should be able to make two slides
Non Functional
How is the system doing a thing? For Ex. A created slide should be displayed in 1 second

Non - Functional

Response Time, Throug­hput, Resource Usage, Reliab­ility, Availa­bility, Failure Recovery, Mainta­ina­bility, Modula­rity, Security, Testab­ility, Learna­bility, Usability, Price, Extens­ibi­lity, Reusab­ility
Non functional requir­ements may be more critical than functional requir­ements, if these are not met, the system is useless! Usually cannot be implem­ented in a single module of a program.

Planning

Planning = Process of deciding: What activities will be performed, when activities should be starte­d/c­omp­leted.
Project Planning = Scope of system as a whole, what order features will be done
Iteration Planning: Which features will be included in the next delive­rable?
Parts of Planning
Which features are most valuable or risky?
Which features will make it into the project or iteration?
How much effort will each feature take?
Does a given feature depend on other features?
Based on all this: in which order will features be implem­ented?
Generally the high priority tasks should be picked first for an iteration
Base the amount of work in an iteration on the velocity of your team
70% tasks in the iteration should be must-haves leaving room for uncert­ainty (based on worst + average case estimates)

Tracking

Process of determ­ining: when and what tasks got completed.

Tracking + planning = extent to which a project in on schedu­le/cost can be monitored.

TDD Techniques

Triang­ulation (Playing Diffic­ult):
Referring to how we're using multiple bearings to pinpoint the implem­ent­ation towards the proper implem­ent­ation
Using a test double
As altern­ative and suitable implem­ent­ations of an interface or class that we don't want to use in a test
 
This is because it's too slow, or not available or depends something not available or is just too difficult to instan­tiate

Objects

Object = a chunk of structured data in a running software system
Represents anything with which you can associate properties and behaviour
Properties charac­terize the object - describing it's current state
Behaviour = the way an object acts and reacts to the possible changing of its state

Classes

Class = a software module that represents and defines a set of similar objects.
Object with same properties + behaviour = instances of one class
Class contains all of the code that relates to its objects. This includes data for implem­enting properties and procedures (AKA methods) for implem­enting behaviour
Instance Variables = Each class declares a list of variables corres­ponding to data that will be present in each instance
Naming Classes
Noun or noun phrase
Singular
Capita­liz­ation Style: Pascal Case
No Space: PartTi­meE­mployee
Do not use underscore (_)
Neither too general nor too specific (city should be munici­pality)
Avoid reflecting the internals of the system ("Re­cord, Table, Data, Structure, or Inform­ati­on")

Interface vs Abstract

- In Java, a class only derive from one other class = no multiple inheri­tance in Java (inherit only one abstract class)
- But a class can implement multiple interf­aces.
- Abstract classes = meant for inheri­tance to form a strong relati­onship between two classes. Can have some implem­ent­ation code.
- Interface = no method defini­tio­n/only method headings
When to use?
Abstract = Inheri­tance (Gives a base class), having non-public members, to add new methods later on
Interface = The API will not change for a while, similar to multiple inheri­tance, has all public members

Commun­ication Diagram Details

1. The classes of the two objects have an associ­ation between them (same direction = unidir­ect­ional)
2. The receiving object is stored in a local variable of the sending method. Object created in the sending method or some comput­ation returns an object (<<­loc­al>> or [L])
3. A reference to the receiving object has been received as a parameter of the sending method. (<<­par­ame­ter­>> or [P])
4. The receiving object is global. When reference to an object is obtained using a static method. (<<­glo­bal­>> or [G])
5. The objects commun­icate over a network. (<<­net­wor­k>>)

API

API = applic­ation progra­mming interface
An API is provided by a piece of software - abstracts away the implem­ent­ation of the software
An API is used by other pieces of software. Two pieces interact via API (API acts a contract between them)

The Process of Design

Design = problem solving process to find and describe a way:
- to implement the system's functional reqs.
- respect the constr­aints imposed by non-fu­nct­ional reqs. (budget, deadli­nes..)
- adhere to general principles of good quality
Design Issues = sub problems of the overall design. Each issue has several altern­ative solutions. The designer makes a design decision to resolve each issue. This involves choosing what he or she consider to be the best option from among the altern­atives.
Good design = increasing profit with reduced cost, ensure confor­mation to the reqs., accele­rating develo­pment, increasing usability, effici­ency, reliab­ility, mainta­ina­bility and reusab­ility
They use knowledge of the reqs., the design created so far, the tech. available, software design principles and 'best practices' and past experi­ences.
 

Comments

No comments yet. Add yours below!

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.

          Related Cheat Sheets

          ISTQB Test Automation Engineering Cheat Sheet
          Python Software Engineering Best Practices Cheat Sheet