Midterm Study Guide Shared PDF

Preview

Summary

Professor Kristina Nasr; Mega study guide...

Description

IN4MATX 43 - Midterm: Piazza Group Study Guide Fall 2019 INF 43 Midterm Study Guide Only use this as a reference; this may not be 100% correct Please fix any errors and or contribute to elaborate on answers

Lecture 1 & 2 Quoted Definition of SE: According to the study guide, remember one of the quoted definitions word-for-word

-

“A broad field that touches upon all aspects of developing and supporting a software system” -- Tsui, Karam, Bernal’

-

“A discipline that deals with the building of software systems which are so large that they are built by a team or teams of engineers” -- Ghezzi, Jazayeri,

Mandrioli -

“Multi-person construction of multi-version software” -- Parnas

-

“A discipline whose aim is the production of fault-free software, delivered ontime and within budget, that satisfies the user’s needs. Furthermore, the software must be easy to modify when the user’s needs change” -- Schach

3 Essential Ingredients of SE: -

People, process, tools

3 Perspectives on SE: -

-

Business -

Focus on money, i.e. staggering costs and incomes

-

Focus on cost, time, profit

Engineer -

-

Focused on internal quality of software

User -

Focused on external quality of software

Recurring, Fundamental Principles of SE (DIAGRAMS): -

Rigor and formality -

Build quality software

IN4MATX 43 - Midterm: Piazza Group Study Guide Fall 2019 -

Separation of concerns: -

Modularity -

-

Divide and conquer -

-

Easy to build, test, maintain, extend, etc

Dissecting a big task

Abstraction -

Design technique

-

Anticipation of change

-

Generality -

Developing software free from unnatural restrictions is important

-

Related to anticipation of change; general-use software = usable in more situations = better in a world with constantly changing needs!

-

Incrementality -

Slowly adding onto software and testing it over time simplifies verification and minimizes time needed to implement changes

Lecture 3 & 4 Software Failure Causes: -

Lack of user input or involvement

-

Incomplete requirement specifications

-

Changing requirements and specifications

-

Lack of discipline in the development process

-

Lack methodical usage of metrics

-

Lack of resources

Requirements: -

What the software should do (without saying how it should do it)

-

Requirements analysis: the activity of discovering/observing/gathering the customers’ needs (find out what the customers use the feature for, not what they say they want)

IN4MATX 43 - Midterm: Piazza Group Study Guide Fall 2019 -

Requirements specification: the activity of describing and documenting customers’ needs

Why it’s important to spend a lot of time on requirements: -

Requirement phase is before any concrete coding has been done, therefore changes can be easily made without losing any progress

-

Requirement defects are expensive. Lack of user input listed as frequent problem. Key contributors to project failure relate to requirements.g

-

Most projects stumble or fail as a result of poor requirements.

-

Because requirements specification is the source for all future steps in the software cycle

What happens in the requirements phase: -

Planning, interviewing clients, making requirement diagrams & use cases, etc

Which category employs the most programmers in the US: -

Consulting companies / Contract programming

Techniques for requirements analysis: -

Interviewing customers, observing (shadowing) customers

-

Creating use cases, scenarios, “stories”

-

Prototyping

-

Identifying important factors (objects, roles, functions, goals)

-

Conducting research, gathering data, constructing model

Structure of a requirements document: -

Intro: executive summary, project overview, application context -

Generally a very high-level overview of the projects. No specifics should be mentioned (like OS, language, etc)

-

Requirements: environmental, functional, non-functional, other -

Be specific in this section, down to every last detail

-

Environmental: OS’s, languages, standards, type of machine, etc

-

Functional: concepts, functions, features, information; abstraction

-

Non-Functional (software qual-ities): reliability, portability, security, etc

IN4MATX 43 - Midterm: Piazza Group Study Guide Fall 2019 -

Other: cost, documentation, tutorials, on-site training, etc

Risks, assumptions, and future changes -

Risks are “future uncertain events with a probability of occurrence and a potential for loss”

-

Assumptions - Factors that are believed to be true during the life cycle of the project

-

Uncertainties or assumptions that are a key factor to the software

-

What are the potential future changes in the future? It’s better to identify them up-front in the planning phase; changeability matters

-

Structure the document so that it can easily “absorb” changes

Others: -

Glossary of terms

-

Reference documents

-

UI, interfaces, etc

Ziv’s Law (emphasizing the uncertainty of the process): -

Software development is unpredictable and the documented artifacts such as requirements will never be fully understood

-

Uncertainty is inherent and inevitable in SE processes and products

Use Cases: -

Definition: textual descriptions defining interactions between users and

IN4MATX 43 - Midterm: Piazza Group Study Guide Fall 2019 systems to achieve goals -

Actors: -

The users that will interact with the system “Users” can contain non-human actors: for example a scheduler API

-

Can be linked together with inheritance (head chef ⇒ chef)

-

Primary actor is most often the human that “uses” the system

-

Two actors linked to a use case means AND relationship!!! NOT OR!!! The two actors must be simultaneously present to “access” the use case TWO LINK AND

-

Flows: -

Basic flow: the “happy” flow where everything goes according to plan, the goal is achieved I cooked my lunch with the ingredients in the fridge

-

Alternative flow: another way of achieving the goal Dammit, I’m out of sauce. I go get some and cooked my lunch successfully

-

Exception flow: something went wrong, the goal is not achieved Dammit, I’m out of sauce and there are no shops selling sauce. No lunch :( BAE

-

Use Case Diagrams: -

Actors are represented as stick figures (even if they are not always human)

-

Use cases are the number of “bubbles” in the diagram

-

Good for functional requirements but useless for systems without them

-

- basically elaborates further on a use case; E.g, ordering wine elaborates on ordering food

-

- the use case with the arrow sticking out (A), invokes the use case the arrow stabs (B) E.g, enrolling in UCI means enrolling in a major

-

Regular arrows - if you see them pointing from an actor to another… the former is inheriting from the latter.

IN4MATX 43 - Midterm: Piazza Group Study Guide Fall 2019 -

Use cases should capture all possible flows

-

Example: (credit to wiki)

Lecture 5 & 6 Software Architecture: -

Definition: the set of principal design decisions regarding the system; the blueprint for a software system’s construction and evolution

-

BP FOR C&E

-

Elements of Software Architecture (CCC): -

-

Components -

Data

-

Processing

-

Client, server, peer, logger, load balance, UI

Connectors -

Interactions

IN4MATX 43 - Midterm: Piazza Group Study Guide Fall 2019 -

Function calls, messages, shared data, repositories, information streams, protocols

-

Configurations (arranged using components and connectors)

Architectural Erosion: -

Definition: when the descriptive architecture “outgrows” the prescriptive architecture; when a system evolves and its prescriptive architecture is not updated.

-

Outgrow and not updated

-

Prescriptive architecture: what the software is intended to be (as designed/ as intended)

-

Descriptive

architecture:

what

the

software

implemented/as realized) Software Architecture Styles (CLOMPPP): -

-

Object-Oriented (example: Uber)

-

Understandability, abstraction, changeability

-

E.g: Business applications

-

OO DESIGN (UAC) COMPANY USE

Model-View-Controller (example: ATM)

really

is

(as

IN4MATX 43 - Midterm: Piazza Group Study Guide Fall 2019

-

Modularity,

changeability

The controller manipulates the model -

The model updates the view

-

The view is what the user sees and the user uses the controller to interact with the system

-

-

-

E.g. web apps, mobile apps.

-

MVC(MC) PERSONAL USE

Client-Server (example: Minecraft)

-

Shared data and services, centralized control

-

E.g. email, web/mobile apps.

-

CS (SC) compare with P2P game/email

Layered (black box) (example: restaurant) -

Modularity, abstraction, changeability, reusability

-

The most reusable layer is the lowest layer

IN4MATX 43 - Midterm: Piazza Group Study Guide Fall 2019

-

-

-

-

E.g. operating system, networks

-

BB(MACR) require and get

Peer-to-Peer (P2P) (example: Discord :thinking: discord for 43?) -

Efficiency, robustness

-

E.g. file sharing system, skype, zoom, bitcoin

-

BB(ER)

Pipe-and-Filter (example: compiler）

-

Modularity, changeability, reusability

-

E.g. Unix shell, compilers

-

PF（MCR）

Publish-Subscribe (Pub-Sub) (example: stock market ticker)

-

Efficiency, scalability

-

E.g. stock market, news

-

pubsub(es)

Software Architecture Evolution: -

All successful software evolves!

IN4MATX 43 - Midterm: Piazza Group Study Guide Fall 2019

-

Should be accommodated as much as possible in the planning phase

-

Architecture is a key tool in accommodating evolution

Lecture 7 Approaches to Software Design (SOURFS): -

Software architecture

-

Functional decomposition

-

Relational database design

-

Object-oriented and UML

-

UI design

-

(sketching)

-

SFROU

Software Design Purposes: -

Think: people think more about the software in the designing process

-

Talk: people will often talk to experts in the field when designing Rubber ducking: https://bit.ly/2NhvY9u (video explaining how it works) Note: this is just for fun and was only briefly mentioned in the lecture, probably not on exam

-

Prescribe

Abstraction: -

Exactly what it sounds like: hiding irrelevant information in order to highlight important information

-

Every design notation support some degree of abstraction

-

SE is all about constructing and elaborating on the models

IN4MATX 43 - Midterm: Piazza Group Study Guide Fall 2019 UML Class Diagrams: -

Decomposes a system into different “classes”; show relations in between

-

Can hide non-crucial methods and attributes

-

Cardinality of classes (x to x relationships); example: 1 person to 1 pizza 1…* person to 1…* pizza works, and if you really want to, 1 person to 1…* pizza works too

-

Example diagram: (credit to cw88057)

UML Activity Diagrams: -

Shows the flow of functionalities instead of the code Kinda like a finite state machine

-

If something is complicated, an activity diagram might be better than class

-

Example diagram: (credit to freeprojectz)

IN4MATX 43 - Midterm: Piazza Group Study Guide Fall 2019

UML Sequence Diagram: -

Shows different states’/actors’ relationships

-

Focuses on how they connect with each other

-

Example diagram: (credit to Katelynn Copp)

IN4MATX 43 - Midterm: Piazza Group Study Guide Fall 2019

Other Diagrams: -

UI mockups: sketching some interfaces and how they “jump” to each other

-

Pseudo code: well yes (code), but actually (not code)

-

Entity-Relationship diagram

-

Storyboard, sketches, etc

High Cohesion, Low Coupling: -

High cohesion: grouping related functionalities All util methods go into a util class; all UI methods go into a UI class; all controllers... etc

-

Low coupling: ungrouping unrelated functionalities (reduced interdependency) Ex: UI methods does not go into the controller classes

-

Benefits: changes don’t propagate (no chain reactions); reusability

No chain reactions and reusability Discussion 1 -- NSB / SFC No Silver Bullet: -

Four inherent properties: -

Complexity: software is more complex than any other human construct

IN4MATX 43 - Midterm: Piazza Group Study Guide Fall 2019 No two pieces of software are alike

-

-

Conformity: software must conform to a human-created specifications

-

Changeability: software are constantly being updated after release

-

Invisibility: software has no obvious blueprint or graphic representation

-

CCCI difficulty of software

Potential Silver Bullets: -

Buying vs Building (the “black box”)

-

Requirement refinement and rapid prototyping

-

Incremental development: more releases, get feedback from previous

-

Great designers

-

BB->Rapid start-> develop

Software Failure Causes: -

Lack of user input/involvement ← Requirements issues

-

Incomplete requirements and specification ← Requirements issues

-

Changing requirements and specifications ← Requirements issues

-

Lack of discipline in development processes ← Lack of rigor/formality

-

Lack of methodical usage of metrics ← Lack of rigor/formality Ex: If you have an API, you need to worry about the response time (methodical usage) in addition to the # of hits your API is receiving.

-

Lack of resources

Discussion 2 -- Use Cases Fitness App Use Cases (add more, guys~): -

Create new fitness goal: -

Basic Flow: 1. User selects menu and choose “add new goal” 2. User enters new goal’s name and description 3. User sets the requirement to achieve the goal 4. User presses the save button

IN4MATX 43 - Midterm: Piazza Group Study Guide Fall 2019 5. App saves goal, shows notification, and jumps back to home -

-

Saw Alternative Flow -- name already exists: -

Step 2: the name already exists, the app prompts to rename

-

User renames to a valid name

Exception Flow -- failed to save: -

Step 4: User does not press the save button and exits the application

-

The fitness goal resets and no goal is created

(add more)

Discussion 3 -- Mythical Man Month Common Causes of Late Projects: -

Optimism: -

Developers are almost always optimistic. This lead them to believe that everything will go well (without bugs, perfect integration, etc)

-

The “man-month”: -

The “man-month” measurement of work is terribly inaccurate because it assumes that no communication is needed

-

System tests: -

Testing is affected the most by time constraints and other limitations, so this becomes the most mis-scheduled part of development and should be the most prioritized phase during planning as a result

-

Gutless estimating: -

Development times can’t really be accurately estimated or even controlled by changes in the development software; it’s like turning up the heat to cook something faster only to have it cooked extremely unevenly. Considered “gutless” because project managers are afraid to tell the client the real amount of time the project could take since it is most definitely longer.

IN4MATX 43 - Midterm: Piazza Group Study Guide Fall 2019 -

Regenerative schedule disaster: -

Rescheduling a project’s development as it is constantly changing is very difficult and cannot be accurately done.

Thanks @Isiah for helping with this section

Brook’s Law: -

Law: “Adding manpower to a late software project makes it later”

-

Formula: x = n * (n-1) / 2 x = the number of communication channels; n = the number of people in a team More will alter

Discussion 4 -- UML Diagrams

See above sections regarding UML diagrams Helpful video explaining the concept: https://bit.ly/34edYDS More

relevant

video:

https://www.youtube.com/watch?v=UI6lqHOVHic

Making a UML Diagram: 1. Make a big box

2. Label it with a name in CamelCase: Snack, Person, AmazonEmployee

3. Give it a bunch of attributes and methods (this is optional in UML)

IN4MATX 43 - Midterm: Piazza ...