×
Log in to StudySoup
Get Full Access to GATech - Study Guide - Midterm
Join StudySoup for FREE
Get Full Access to GATech - Study Guide - Midterm

Already have an account? Login here
×
Reset your password

What is fault tolerance?

What is fault tolerance?

Description

CS 2340 Spring 2019 Exam 1 Study Guide  


What is fault tolerance?



ANDROID BASICS  

What is android

∙ An OS

∙ Based on BSD (unix/linux)

∙ NDK - native development kit (We won't be using this )

o C++ API

o Augment the OS

∙ SDK - software development kit (like java fx)

o Java API

o Latest version 9.0

∙ Phone has own features of operating machine (?)

Model View Controller  

∙ Model: the business objects and logic for the application

∙ View: visual presentation of information to user

∙ Controller: taking user inputs and passing data and requests to the model


What is single responsibility principle (srp)?



Common terms  

∙ Activity: visual representation of an android application

o Uses both views and fragments to create a UI

o Normally one for each screen

∙ Fragment: optional constructs inside activities to:

o support display on different devices (i.e. phone and tablet) or  o provide reuse across multiple activities or  If you want to learn more check out It is considered to be the city of mambo. what is it?

o to support swiping  

∙ View group

o Basically a layout manager to establish where the view will go on the  actual screen

∙ Intent

o An async message that allows the application to request functionality  from other components

∙ Will use this class a lot  


Who is responsible for creating a new instance of a class?



∙ Service

o A background task that does not require a UI component ∙ Content provider

o An interface to shared application data

∙ Usually the on-board SQLite database

∙ Broadcast receiver

o Deliver events to the app outside of regular program flow  

Packing and Deployment

∙ The compiled code you write along with resources and support are compiled  into a .apk file

∙ The organization, permissions, and instructions on how to run your program  are in a file called AndroidManifest.xml If you want to learn more check out How does the criminal justice system perpetuate racial inequality?

Activity lifecycle

CS 2340 Spring 2019 Exam 1 Study Guide  

3 main states: Paused,  

Resumed/Running, Stopped

onPause() - everyone freezes,  time stops, etc.

onStop() - if app stops/crashes  save a temp file so you can get  back to  

***only need onCreate() for  basic requirements

∙ All others XC

Callbacks:

∙ onCreate()

∙ onStart()

∙ onResume()

∙ onPause()

∙ onStop()

∙ onRestart()

∙ onDestroy()

Important pairs:

∙ Create - destroy

∙ Start - stop

∙ Resume - pause

We also discuss several other topics like Define attachment.

OOP

The challenge: complexity

Design paradigms:

∙ Procedural  

o Fortran, cobol, C, Ada-81

o "verb-oriented development"

∙ OO

o C++, Java, Smalltalk, Ada-95, Ruby

o "noun-oriented"

∙ Functional

o fp, sml, Scala, OCAML, F#

o Can be brutal when you first start learning it  

o One of them is built off .NET (missed which he said) ∙ Logic

o Prolog

Goal of OO

∙ Find a better way to modularize large programs by hiding details

CS 2340 Spring 2019 Exam 1 Study Guide  

∙ Find a better way to reuse software by creating software IC's (Integrated  circuits)

o OO did not actually follow thru on this  

o We do have this on small scale- like collection classes, data structures,  etc.

∙ Find a better way to understand large systems through abstraction

Ex. Sending flowers  

Procedur al

∙ Verb: think of everything you need  to DO

∙ We need a data structure called  Flower

o Needs color, cost, species  ∙ Need an Arrangement o Flower[], cost, container ∙ Need to be able to make an order  (customer info), deliver order, create invoice ∙ THEN you can start coding

OO

∙ Noun: think of the things you need ∙ Customer - who is sending flowers ∙ Recipient - receives flower  ∙ Florist - satisfy customer  ∙ Arranger - turns flowers into  arrangement  

∙ Deliverer - deliver flowers  ∙ Grower - creates flowers  ∙ Wholesaler - provides fresh flowers

If you want to learn more check out What doesn't real gdp measure?
We also discuss several other topics like How are seeds so successful?

OO mantra

∙ Objects do the work.  

∙ The word is done in instance methods in appropriate class  ∙ Good objects have clear, cohesive rules / responsibilities and clear, focused  interfaces

∙ Budd: OOP is structured as a community of interacting / collaborating agents  called objects

o Each object has a role to play

o Each object provides a service or performs and action used by other  members of the community  

∙ *** if you only have static methods, you essentially wrote a C program in Java

What is an object

∙ Knows info

∙ Performs services

∙ Maintains connection

o To other objects (interactions)

o Activities depend on models, etc.

∙ Makes decisions  

o What to send to other objects

CS 2340 Spring 2019 Exam 1 Study Guide  

Fault Tolerance  

Fault Tolerance: property that enables a system to continue operating properly in  the event of the failure of some of its components. If its operating quality decreases, the decrease is proportional to the severity of the failure  Don't forget about the age old question of Where does the ci act?

Builder: for highly configurable objects  

∙ Use when a class has a gazillion different ways to be constructed o Like a bunch of different constructor chaining with optionals ∙ Used INSTEAD OF constructors  

Kinds of problems

∙ Transient: happen once in a while, not a big problem- want to handle but not  declare an emergency

o Network is down and can't connect  

∙ Persistent: happens frequently and indicates we have a problem- time to take emergency action

∙ Ex. database response taking a long time: how to know if transient or  persistent?

Patterns

∙ Leaky bucket pattern

o Think of errors like water coming into leaky bucket:  

∙ Bucket holds certain # of things- but at some point it begins to  leak/overflow

o When bucket leaks, we are having persistent issues  

o If bucket doesn't leak, we can handle transient issues ("treat  symptoms")

o If something is becoming persistent issue, software needs to do  something more sophisticated  

o Implementation:

∙ Faults arrive in system

∙ Increment counter

∙ If counter > threshold (size of bucket) -> problem = persistent ∙ Faults handled at some rate

∙ Counter decremented at constant rate (leak)

∙ Rate + threshold are measure of transient v persistent

o Volatile: keyword for something not changed under your control ∙ Circuit breaker problem (a variation of leaky bucket)

o Problem: some error or fault happening over and over and you do not  want it constantly appearing in application

o Soln: circuit breaker

∙ 3 states: open, closed, half-open

∙ Start closed: circuit breaker executes and counts faults &  successes

 All messages going to server every time it asks

 When certain server call fails, circuit breaker remembers

CS 2340 Spring 2019 Exam 1 Study Guide  

∙ Circuit breaker OPENS when threshold of fails exceeded   Waits a time-out period for time set by programmer

∙ Then goes to HALF-OPEN: sends request again.

 If server responds --> closed  

 If fails after time out --> open

∙ RetryPolicy makes it try 3 times before it succeeds  

∙ FallBackPolicy

o instead of immediately failing, it calls backup function which succeeds  

OO Analysis

Organizational Hierarchy

∙ Application = set of interacting objects

∙ Object = implementation of >= 1 roles

∙ Role = set of related responsibilities

∙ Responsibility = obligation to do a task / know info / decide about something  ∙ Collaboration = interaction of objects / roles / both

∙ Contract = agreement outlining terms of collaboration

Term review

∙ Class/Object

∙ Instance

∙ Message

∙ Receiver

∙ Class hierarchy

∙ Inheritance

∙ Overriding/overloading

∙ Polymorphism  

∙ Encapsulation

∙ Abstraction

∙ Info hiding

Drawing the diagram:

∙ Ex. Canvas system

∙ Actors (people that interact with canvas in different ways)

∙ Primary, supporting

∙ Students

∙ instructors

∙ Admins

∙ Banner (the system that holds official grades)

 A 3rd party API

∙ Off-stage

∙ Feds (FERPA)

o Context diagram:

CS 2340 Spring 2019 Exam 1 Study Guide  

o

User stories

User stories: Describe how users will interact

∙ Follow standard format

o As a __, I want to ___, so that I can ___.

o As an instructor, I want to create an assignment so that my students  will be able to work on it  

Characteristics of good user stories

∙ INVEST acronym:  

o Independent: stories should be able to be developed independent of  each other

o Negotiable: do not put implementation language in story ∙ Keep general enough so you have design flexibility

o Valuable: has to provide business value to customer

o Estimable: can't be too big, too complex, or too unfamiliar to  developers

o Small: cannot span an iteration

∙ If too big, break into smaller stories and use bigger story as an  epic

o Testable: must be able to specify acceptance tests for story

Estimation: abstract things called story points

∙ Scales 1, 2, 3 OR Fibonacci  

∙ Relative:

o Pick the easiest story in there and give it 2 points  

o Pick hardest story and assign it the highest # of points  

∙ Planning poker  

o Pick a user story

o Talk about what would go into story  

o Estimate the user story: (#) - look at outliers and why  

∙ Velocity = points/sprint  

For stories in the current iteration / sprint  

∙ List tasks to implement story

∙ List acceptance criteria

∙ List done criteria

Tasks

∙ Details that have to be done for the task

CS 2340 Spring 2019 Exam 1 Study Guide  

o Design assignment creation UI

o Design assignment table for database

o Code UI

o Code SQL for database

o Code controller and model classes

Acceptance scenarios

∙ How do we know if story is working  

∙ Customer's criteria for accepting story as finished

∙ Use Behavior Driven Development (BDD) format

o Given: some initial conditions

o When: user does something in system

o Then: system has some response

Example: Story -account holder withdraws cash

∙ As an account holder, I want to withdraw cash from an ATM so that I can get  money when bank is closed  

o Scenario 1: given account balance = $100

Done Done  

∙ What is team's agreement on work that must be accomplished before story  can be called "done" by team

∙ Different from acceptance criteria which is customer focused ∙ Ex.

o Code is committed to master branch

o Code is reviewed by another development team member o Test cases are written

o Unit tests and UI automation tasks are written

o Feature is tested for accessibility

o Feature is tagged for analytics

∙ Can do team criteria, or custom criteria for what is done done for each story

Epics

∙ For large user story that needs to be broken down

∙ Symptoms

o Estimate is really large compared to other stories '

o Story too big for 1 sprint

∙ Cure

o Split epic into smaller stories, but keep epic

o SPIDR

∙ Spike a story (last choice)

∙ Paths: look for different paths through story  

∙ Interfaces: web/android/ios may be able to split by platform ∙ Data sources: if data can come from multiple sources, split  sources

∙ Rules: if there are a lot of different rules, introduce them slowly  over multiple stories

Story mapping

∙ Select MMF (minimum marketable feature)

∙ Tell story of how a specific user type goes thru story

CS 2340 Spring 2019 Exam 1 Study Guide  

∙ Record each process step & put in order

∙ Apply SPIDR to each step to split  

o Most steps will be epics

Ex. online shopping  

∙ MMF – User visits site and orders an item

o Steps:

o Search of an item

o View the Search Results (Products)

o View a Photo of item

o Select the item for purchase

o Enter payment information

o Enter shipping information

o Confirm order

Domain Model

∙ Domain model: understand customer concepts / terms

o Domain vocabulary: Want everyone on the same page with what  objects are & are called

∙ Need a standard agreed-upon unambiguous vocabulary

Step 1: Brainstorming

∙ Team generates a lot of possible objects

∙ Don't think too hard

∙ Record all ideas

∙ Use multiple techniques  

o Domain analysis - generic list of things/objects/concepts you might  need in domain model

∙ Generally gives you more high level classes  

∙ Ex. monopoly  

∙ Board

∙ Player

∙ Turn

∙ Piece  

∙ Token  

∙ Dice

∙ House

∙ Hotel

∙ Money

∙ Chance  

Step 2: filtering  

∙ Need to reduce big list down to candidate objects we think are in customer  domain

o Remember: customer should recognize every noun we are selecting as  a candidate object

CS 2340 Spring 2019 Exam 1 Study Guide  

∙ Anything else is probably computer-speak and should be  postponed to design

∙ Look for / get rid of:

o Synonyms  

o Attributes - nouns that are just a simple number or string  ∙ Money probably better as an attribute of player  

o Implementation - nouns that represent implementation/design  decisions- not customer domain ideas (networking, servers,  

implementation)

o UI - nouns representing UI ideas (windows, screens, widgets)

Step 3: draw domain model

∙ Candidate classes with their attributes and methods

∙ DO:  

∙ Basic class  boxes

∙ Associations (regular but normally not  aggregration/inheritance

∙ Cardinality  constraints (multiplity)

Don’t  

∙ No visibility markings (public/private) ∙ No  

parameters / return types  ∙ No types of instance data

∙ Format:

name

Attributes  

Things I know

Responsibilitie s

Things I do

∙ Multiplicity:  

o * = [0,infinity)  

∙ Means a student could have any number of classes  

o 1 .. 6

∙ A student has to be in at least 1 but no more than 6 classes  o 1 .. *

∙ Means 1 to any number (at least 1)

o 0, 3

∙ 0 OR 3 (not 1 or 2)

o 0, 1 or 0..1

∙ Both mean 0 or 1

Bounded contexts

∙ For larger systems, concepts may have different meanings for different  functions in a company  

∙ If a domain term means something different to different users, we introduce a bounded context so the domain model can vary between user groups

CS 2340 Spring 2019 Exam 1 Study Guide  

∙ Think of insurance co and domain term policy:

o Underwriting: evaluation of risks; premium calculation

o Inspection: looking at property and establishing value

o Claims: handling requests for payment

Cautions: avoid -  

∙ Develop an application without a domain model

∙ Lose connection between domain model and code

∙ Try to have a pure analysis model

Ex. We're making an OO horse

∙ Event: Design horse based on the stimulus and what it does

∙ Resp.: Design horse to respond based on responsibility

o Aka give it the features it needs in order to do certain responsibilities o Objects are not as well designed in previous 2 methods

Data  

Driven

Event  

Driven

Responsibility  driven

HT

WT

Breed

Color

speed

Spur ->  

move

Hunger ->  eat

Name

Owner

Stall #

Food

Vet treatment

Move()

Trot()

Eat()

createInvoice()

Design Principle:

Single responsibility principle (SRP): each class should have a single responsibility /  single reason to change  

∙ Note: a responsibility is a high-level abstraction of the role of the object/class  plays in our design. It is not at the method level

o i.e. classes can have more than 1 method  

Stereotypes

Information holder

 know things

Service  

provider

do things

May have attributes, but only to be

Structurer

Organize things

Structure keeps track of a big collection of stuff so we can access it

Interfacer

Adapts one part of  a system to

Almost like viewmodel: goes from view,  translates info to model, then pumps it back to

CS 2340 Spring 2019 Exam 1 Study Guide  

another

view

Coordinator To decide things  using set, non

adaptive logic

Always going to route ___ to ___

Ex. traffic light always turns green after 2 min

Controller

To decide things  using adaptive  

logic

Like If messages exceed certain amount,  change what its doing (i.e. if something is  overloaded, reassign tasks)

Ex. a police officer manages traffic and  changes red/green rules based on demand

Adding to the domain model

∙ <<name of stereotype>> in UML << .. >> is called a stereotype goes over  the name of the class for ex.

<< info holder  >>

Name

Addr

email

calcT()

checkDist()

∙ Want to pick one overriding stereotype: if the MAIN REASON of the ^ is to  store the attributes name, address, email, etc, then it's an info holder (it may  have some methods, but they are not the main priority. If the MAIN REASON of  ^ is to have functions (service provider), then it better have at least one  method  

GRASP & OOD

Coupling (High- low)

∙ *Content: one class modifies another  

o Branch into middle of routine, modifies code  

∙ *Common: share common (global) data

o Singleton is a global class  

∙ *Control: use a return code to control a different method

∙ Stamp/data: passing complex data or structures between models ∙ Uncoupled: no relationship  

* = don't do this

Cohesion (high to low)

∙ coincidental: unrelated functions

o Want to avoid!

∙ Logical: multiple logic sections with ext select  

∙ Temporal: related by phases  

∙ Procedural: required ordering of tasks  

∙ Communicational : operate on same set of data

CS 2340 Spring 2019 Exam 1 Study Guide  

∙ Functional: all essential elements for a single function are in the same module

Shoot for:

∙ Low coupling

∙ High cohesion

∙ Low representational gap (LRG)

o Should not have to go to some dictionary to figure out what your class  names mean

∙ Separation of concerns

o Want to keep major parts of application separate  

Things to avoid  

∙ High coupling  

∙ Low cohesion  

∙ Rigidity  

o Every time you need to make a minor change, you need to edit a  bunch of classes

∙ Fragility

o Fix a bug somewhere, everything else breaks as you fix the one thing  ∙ Immobility

o Can't reuse code because completely coupled to the rest of the app  ∙ Hackability (viscosity)

o You have a UI, App, domain, infrastructure:  

o It's easier in a layered architecture, you're only able to talk to layers  immediately next to each other  

∙ Much easier to hack straight to bottom if you need to add  something to UI (not correct way)

∙ Needless complexity (YAGNI)

o Adding a bunch of junk to design "just in case" you need to add  features later  

∙ Needless repetition (DRY)

o DRY = don't repeat yourself

o Don't copy and paste your code around  

∙ Opacity (obscure, obtuse)

o Don't write obscure code  

GRASP: general responsibility assignment software patterns

∙ Creator

o Who is responsible for creating a new instance of a class? o Rules: Assign class B to create class A if:

∙ B contains or aggregates A

∙ B records A

∙ B closely1 uses A

∙ B has initializing data for A

o If >1 option applies, the prefer aggregation

∙ Information expert

o Assigns responsibility to the class that has the info necessary to fulfill  the responsibility

CS 2340 Spring 2019 Exam 1 Study Guide  

∙ Low coupling

o Assign responsibilities so that coupling remains as low as possible  o Not all coupling is bad:

∙ Using collection classes or String for ex  

∙ Why is this not normally a problem?

∙ Class String never changes  

∙ We want to reduce impact of change, so if classes are not  changing then the impact of coupling to them is minimized

∙ Some coupling is normal: you cannot get rid of all coupling  unless you end up with a bunch of silly data objects and one giant  controller object

 Controller  

o AKA Interactor  

o First object past UI that receives and coordinates a system operation ∙ Don't want UI to know all these things  

∙ Just want to talk to an abstract class to get things done  ∙ Can go to interactor and not know all the gruesome class details o Assign responsibility to a class that:

∙ Represents overall system (façade)  

∙ Represents a Use Case scenario where the event occurs o Not exactly same controller as MVC controller - more like presenter in  MVP

o Responsibilities:

∙ Delegates other objects work to be done  

∙ Coordinates and controls activity

∙ Does not do a lot of work itself

∙ Principle: UI objects should not have responsibility for fulfilling  system events

∙ i.e. views are only for displaying info - not processing  ∙ No business stuff hidden in activities  

o Façade controller  

∙ Represents overall system

∙ Suitable when there are not a lot of events to be routed ∙ Most methods are pass-through to actual domain classes doing  the work

o Use case controller

∙ Use when façade would be too bloated, suffer from too high  coupling or too low cohesion

∙ Best when there are many possible system events  

∙ Allows you to separate the control function into separate classes ∙ Clean architecture uses them

o Danger: Bloated Controllers

∙ Using a façade when there are too many system events  ∙ Controller is actually performing the system work instead of  routing to correct domain objects

∙ Controller has many attributes and maintains significant state  information about system

CS 2340 Spring 2019 Exam 1 Study Guide  

∙ FIX BLOAT:

∙ Add more controllers: change from a façade  

controller to use case controllers  

∙ Change controller so it delegates work to domain  

objects  

 High cohesion

o Keep objects manageable, focused, and support Low Coupling o Assign responsibilities so that cohesion remains high

o Objects should not do many unrelated things  

o Ex. Game of checkers

∙ Start small with deciding who should control game loop:  ∙ What class is going to know how to take a turn?

∙ Step 1: analyze what info is required

∙ Step 2: apply Info Expert

∙ Step 3. Evaluate the choice with coupling and cohesion ∙ The info is spread across objects

∙ Guide 1: if there are partial info experts, choose  

dominant one  

∙ Guide 2: if all about equal, considering coupling and

cohesion and choose best  

∙ Guide 3: if still no clear winner, consider future  

evolution of app

 Polymorphism

o How to handle alternatives? How do we create pluggable components? o When variations/alternatives exist, assign responsibilities to types  where behavior varies

o Do not test for type of object and use conditions to pick the correct  behavior  

o Protected variation, indirection, and polymorphism work together to  make your program flexible  

o Ex. POS  

∙ 3rd party tax collectors that we need to support during sale ∙ Who handles calculations?

∙ Might all have different APIs  

∙ Soln: make abstract interface/class that provides standard api ∙ Wrap each 2D party tool in standard interface  

o Ex. Monopoly

∙ Different squares on board do different things

∙ Chance, income ta, go

∙ Do not use case or switch to handle this

∙ These r bad

∙ Use polymorphism

∙ Pure fabrication

o What object should get responsibility for something to comply with  coupling and cohesion, but the info expert solns are not appropriate?

CS 2340 Spring 2019 Exam 1 Study Guide  

o Many times, our OO classes model a physical reality (checker, board,  square), but sometimes we need to "make up" a class

∙ Thus we assign responsibilities to made up classes that can be  highly cohesive  

∙ Indirection

∙ Protected variations  

o How do we assign design objects so that variations or instability  (changes) do not have an impact on other objects

Always in moderation:

∙ 2 kinds of change'

o Variation point: something that is required by our current design ∙ What we have to handle in v1

 Indirection, polymorphism

o Evolution point: something that may arise in the future but is not  required now  

3 developers

∙ Novice - brittle designs

o Easy to code, hard to maintain

∙ Intermediate: overly fancy, flexible, generalzied designs (in ways never used) o Easy to maintain, hard to code  

∙ Experts

o Chose with insight, balancing brittle with generalized

∙ Easy when we can, hard when we have to

Other design principles

∙ LoD: Law of Demeter

∙ TDA (tell don't ask)

Law of Demeter

∙ An object sends messages to

o Itself  

o Objects sent as arguments to message m

o Objects created as part of reaction to m

o Objects directly accessible via my attributes  

∙ Purpose: reduce coupling and fragility

∙ Ex  

o

Databases

∙ ORM: object relational mapping

CS 2340 Spring 2019 Exam 1 Study Guide  

Ex.  

Good

bad

Bad bc still  

chaining  

Same as above

Tell, Don't Ask

∙ Tell objects what to do, don't ask them about internal state and then make  decisions

∙ Isolate business logic to appropriate class

∙ DRY

o

Easy to see if you're violating;

∙ Lots of getData() calls

Command Query Segregation

∙ AKA CQRS - command query responsibility separation

∙ Comes from functioning programming world and deals with side effects ∙ Query - asking for information, should not do any processing  ∙ Command - asking for processing, should not return info

∙ *** somewhat controversial

∙ Types of methods:

o Procedure: does something but returns void  

o Function: returns something  

∙ Ex. Java T pop() violates this  

o Removes item AND return it

Basic Principles (SOLID)

∙ S = single responsibility

∙ O = open/closed

CS 2340 Spring 2019 Exam 1 Study Guide  

∙ L = Liskov substitution

∙ I = interface segregation

∙ D = dependency inversion

∙ Single responsibility

o Each class should have a single overriding responsibility (high  cohesion)

o Each class has 1 reason why it should change  

o  ∙ Open closed

o Indirection, polymorphism, protected variation

o Objects open for extension (adding new features) but closed for  modification (can't edit)

∙ Extension via inheritance, polymorphism

∙ Related design patterns: template, state, strategy

Ex. write a statement that will compute pay no matter what  the category is

Have 1 compute method that  does all of them

∙ Ex. shape: drawAllShapes is a switch w case for each shape in shapeType  ∙ Instead do for each shape, shape.draw()

 Then you only have to add the shape to the shapeType enum

∙ Liskov Substitution Property  

∙ If for object o1 of type S, there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1  is substituted for o2, then S is a subtype of T  

∙ Essentially saying subclasses should be suitable for base classes

∙ Contract implications

∙ Preconditions cannot be strengthened in the subclass

∙ Postconditions cannot be weakened in subclass

∙ If function refers to base class but has to know the specific subclass, it  probably violates this principle

CS 2340 Spring 2019 Exam 1 Study Guide  

∙ Dependency inversion principle (Dependency Injection)

∙ Depends on abstractions, not concretions

∙ Program to interfaces not implementations  

∙ Program to most abstract class possible  

∙ Hollywood principle  

Bad

Good

∙ Using inversion:

Not using inversion

Using inversion

∙ Interface segregation principle

∙ Don't make large multipurpose interfaces - instead, use several small  focused ones  

∙ Don't make clients depend on interfaces they don't use

∙ Class should depend on each other through the smallest possible  interface  

∙ Basic design:

∙ Abstract class vs interface  

∙ Sometimes it's a wash

∙ Sometimes a critical decision

CS 2340 Spring 2019 Exam 1 Study Guide  

∙ If you only have method signatures, use interface  

∙ If you have some attributes, abstract class  

∙ Class vs attribute  

∙ Avoid primitive obsession

∙ Make classes when it makes sense based on reuse and functionality System Architecture  

System is an integrated composite of

∙ people

∙ products (hardware, software)

∙ processes

software architecture

∙ part of overall system architecture

∙ "components & connectors"

∙ A software architecture for a program or computing system consists of  the structures of that system, which comprise elements, the externally  visible properties of those elements, and the relationships among them

Architectural Views

∙ A view is the a representation of a set of system elements and the relations  associated with them

∙ representation of the many system structures present simultaneously in  software systems

∙ standard views:

o 4 + 1 views

∙ conceptual

∙ describe how things work at runtime

CS 2340 Spring 2019 Exam 1 Study Guide  

∙ physical:  

∙ used for hardware and servers

∙ module:

∙ + 1 --> use case (user stories)

Architectural Styles

∙ a specialization of element types (e.g., client,” “layer”) and relationship  types (e.g., “is part of,” “request-reply connection,” “is allowed to use”),  along with any restrictions (e.g., “clients interact with servers but not each  other” or “all the software comprises layers arranged in a stack such that  each layer can only use software in the next lower layer”).

∙ common styles

o Client – Server

∙ very common

∙ thin: most or all of the processing power happens on the server  (client isn't doing much)

∙ ex) canvas --> you tell your web browser to go to canvas  and don’t have to download anything, the server prepares all of it for  you

∙ fat: your client does a lot more

∙ ex) big downloads required because the app actually does stuff

∙ what happens when a server goes down? -> failure  o Peer-to-Peer

∙ many clients exchanging information with one another and the  app's state is stored on each individual machine

∙ ex) multiplayer games, if one person's server goes down,  everyone else can keep playing

∙ used in illegally distributing media ex) pirating movies or songs o Blackboard/Shared Memory

∙ solve a problem using many partial solutions

∙ big thing of shared memory called a blackboard that all the  partial solvers look at and update as solutions are found

o Pipe and Filter

∙ read in information, then pass data to the next step: "filters" ∙ NOT user interactive

∙ good for processing that requires lots of stages

o Model – View – Controller

o n-tier

∙ tiers that prevent communication except between adjacent tiers

CS 2340 Spring 2019 Exam 1 Study Guide  

∙ ex) 3 tier architecture: client, app, database

∙ client can't talk to the database themselves

o Layered

∙ a function within a layer can only talk to things in its adjacent  layers

,

∙ Implement algorithms only one time, in the comp/decomp layer

o Implicit Invocation/Event-Driven

∙ low coupled system

∙ no function calls

∙ as events happen, we program appropriate responses ∙ but we have to implement a whole "event bus": specify exactly  which events we are interested in and prepared to handle

CS 2340 Spring 2019 Exam 1 Study Guide  ∙

Page Expired
5off
It looks like your free minutes have expired! Lucky for you we have all the content you need, just sign up here