SENG 301 Cheat Sheet

by brownie5 via cheatography.com/27396/cs/7936/

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 3. We can get reliable user feedback
system)

4. Increm​ental fundam​entally means add onto and helps you to improve your 4. Good for big projects
proc​ess

5. Only major reqs. can be defined, details may evolve over time

6. Iterative fundam​entally means redo and helps you to improve you

prod​uct

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:
Throw​away = Example is a paper one. Will be used only for evalua​tion;Incre​mental = created a separate compon​ents; Evolu​tio​nary = refined to
become actual product
Prot​otype Fideli​ty:
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)
Prot​otyping can help answer:

By brownie5 Published 20th April, 2016. Sponsored by Readability-Score.com

cheatography.com/brownie5/ Last updated 20th April, 2016. Measure your website readability!
Page 1 of 12. https://readability-score.com
 SENG 301 Cheat Sheet
by brownie5 via cheatography.com/27396/cs/7936/

Protot​yping (cont)

- 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
Acce​ptance 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

Gene​ral​iza​tion: Specia​lizing a superclass into subcla​sses. Avoid unnece​ssary genera​liz​ations

Depe​nde​ncy: Used for extremely weak relati​​on​ships between classes. Ex. A class makes use of a library

Aggr​ega​tion: Represents "​par​t-w​hol​e" relati​ons​hips. The whole side is called the aggregate. Aggreg​ations are read as "is part of"

Comp​osi​tion: Are strong forms of aggreg​ation. If the aggregate is destroyed, then the parts are also destroyed.

Aggr​ega​tion = 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

By brownie5 Published 20th April, 2016. Sponsored by Readability-Score.com

cheatography.com/brownie5/ Last updated 20th April, 2016. Measure your website readability!
Page 2 of 12. https://readability-score.com
 SENG 301 Cheat Sheet
by brownie5 via cheatography.com/27396/cs/7936/

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)

By brownie5 Published 20th April, 2016. Sponsored by Readability-Score.com

cheatography.com/brownie5/ Last updated 20th April, 2016. Measure your website readability!
Page 3 of 12. https://readability-score.com
 SENG 301 Cheat Sheet
by brownie5 via cheatography.com/27396/cs/7936/

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​ect​ure:
- 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​ect​ure
- All UML diagrams = useful for describing aspects of the archi. model

Archit​ecture using UML diagrams particular = Package, subsystem, component, deployment

By brownie5 Published 20th April, 2016. Sponsored by Readability-Score.com

cheatography.com/brownie5/ Last updated 20th April, 2016. Measure your website readability!
Page 4 of 12. https://readability-score.com
 SENG 301 Cheat Sheet
by brownie5 via cheatography.com/27396/cs/7936/

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

Elic​ita​tion = Surveys, analysing existing documents, brains​tor​ming, model driven techni​ques, observ​ation or card sorting
Mode​lling = Data, Enterp​rise, Behavi​oural, Domain or non-fu​nct​ional reqs.
Comm​uni​cat​ing = Effective commun​ication among different stakeh​olders
Agre​eing = Verifi​cation and valida​tion, requir​ement conflicts, requir​ement risks, stakeh​older conflicts
Evol​ving = 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 over​ride M

Dependency vs. Associ​ation

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

By brownie5 Published 20th April, 2016. Sponsored by Readability-Score.com

cheatography.com/brownie5/ Last updated 20th April, 2016. Measure your website readability!
Page 5 of 12. https://readability-score.com
 SENG 301 Cheat Sheet
by brownie5 via cheatography.com/27396/cs/7936/

Aggreg​ation vs Compos​ition

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

Sequence vs. Commun​ication

Sequ​ence = good for explicit ordering of intera​ctions (Inter​action model Comm​uni​cat​ion = Adding details to class diagrams (validates a class
for use case = use case make time ordering explicit) 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​ab Capability of the system to enable a specified modifi​cation to be implem​ented.

ility

Portab​ility Capability of the software system to be transf​erred from one enviro​nment to another

Extens​ibil Capability of the software system to enable the implem​ent​ation of extensions to expand or enhance the system (new capabi​lities and features)
ity with minimal impact to the existing systems

Testab​ilit Capability of the software system to enable modified software to be validated

y

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

By brownie5 Published 20th April, 2016. Sponsored by Readability-Score.com

cheatography.com/brownie5/ Last updated 20th April, 2016. Measure your website readability!
Page 6 of 12. https://readability-score.com
 SENG 301 Cheat Sheet
by brownie5 via cheatography.com/27396/cs/7936/

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
Post​con​dit​ions: 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 Objective = Checks the functional Check that the software product meets Whether the system is well-
stages of the develo​pment cycle behaviour of the system the customer's actual needs e​ngi​neered? Error free?

Are we building the product right? Are we building the right product? Dynamic Static

By brownie5 Published 20th April, 2016. Sponsored by Readability-Score.com

cheatography.com/brownie5/ Last updated 20th April, 2016. Measure your website readability!
Page 7 of 12. https://readability-score.com
 SENG 301 Cheat Sheet
by brownie5 via cheatography.com/27396/cs/7936/

Static vs Dynamic Testing (cont)

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. SoTrust but verify, verify but also valida​te.

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

Expl​ora​tory = 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 synch​ron​ized

Testing Strate​gies
- 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 = orga​nizing procedural abstra​ctions in the context of data abstra​cti​ons

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

By brownie5 Published 20th April, 2016. Sponsored by Readability-Score.com

cheatography.com/brownie5/ Last updated 20th April, 2016. Measure your website readability!
Page 8 of 12. https://readability-score.com
 SENG 301 Cheat Sheet
by brownie5 via cheatography.com/27396/cs/7936/

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

Inte​raction Diagra​ms: 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 Diagra​ms: An intera​ction diagram that focuses on the sequence of messages exchanged by a set of objects performing a certain task

Comm​uni​cation Diagra​ms: 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

Inte​raction Diagrams Show (Inter​act​ion) = the steps of the use case, the steps of a piece of functi​ona​lity. Composed of instances of classes, actors and
messages.
Sequence Diagra​ms: Can represent condit​ional logic and loops and show explicit destru​ction of objects.
Comm​uni​cation 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!)

By brownie5 Published 20th April, 2016. Sponsored by Readability-Score.com

cheatography.com/brownie5/ Last updated 20th April, 2016. Measure your website readability!
Page 9 of 12. https://readability-score.com
 SENG 301 Cheat Sheet
by brownie5 via cheatography.com/27396/cs/7936/

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​emen 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
t users will expect

Functional Inputs the system should accept; Outputs the system should produce; Data the system should store that other systems might use;
Requir​emen Comput​ations the system should perform (Not algori​thms); Timing and sync. of the above (Not response time but the ordering of events)
ts

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.

By brownie5 Published 20th April, 2016. Sponsored by Readability-Score.com

cheatography.com/brownie5/ Last updated 20th April, 2016. Measure your website readability!
Page 10 of 12. https://readability-score.com
 SENG 301 Cheat Sheet
by brownie5 via cheatography.com/27396/cs/7936/

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

By brownie5 Published 20th April, 2016. Sponsored by Readability-Score.com

cheatography.com/brownie5/ Last updated 20th April, 2016. Measure your website readability!
Page 11 of 12. https://readability-score.com
 SENG 301 Cheat Sheet
by brownie5 via cheatography.com/27396/cs/7936/

Classes (cont)

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
Inter​face = 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.

By brownie5 Published 20th April, 2016. Sponsored by Readability-Score.com

cheatography.com/brownie5/ Last updated 20th April, 2016. Measure your website readability!
Page 12 of 12. https://readability-score.com