Informatics 43 Midterm

What is software engineering?

"Multi-person construction of multi-version software."

Perspectives on Software Engineering

Business: Cost, time, profit Engineering: Internal quality Design: External Quality

User Interface Design

Flow of interactions, look and feel

Functional Decomposition

Functional Decomposition is the idea that we can divide and break a long program into smaller pieces, where each piece can be solved more easily. Each piece will represent its own unique function if the bigger piece is a program, and will be unique to completing a single task. it will be easier to see what part of the program does which task, and is easier to debug instead of looking through the entire program and trying to spot the error.

Information Hiding

Hide design decisions that are most likely to change, thereby protecting other parts of the program from change if the design decision is changed.

High Coupling/Low Cohesion

High Cohesion: Grouping related functionality (Easier to find things) Low Coupling: Ungrouping unrelated functionality / reducing interdependency (Changes don't propagate, Reuse is facilitated)

Relationships Between Classes

Inheritance Association (Multiplicity) Whole-part (Aggregation and Composition)

Requirements Document Structure

Introduction, Executive summary, Application context, Enviromental requirements, Functional requirements, Software qualities/non-functional requirements, Other requirements, Time schedule, Potential risks, Assumptions, Future changes, Glossary, Reference Documents

Design Phase of Software Engineering

Requirements > Design > Implementation > Verification > Maintainance

Use Case Definition

Textual description defining interactions between an actor and the system to achieve the primary actor's goal (includes different scenarios/flows[basic, alternative, exception])

Client-Server

Where you have a layer between server and client (UI) and interactions happen through it.

Brooks' Law Formula

n(n - 1)/2

Architectural Style

A named collection of architectural design decisions that: are applicable in a given development context, constrain architectural design decisions, and result in beneficial qualities in each resulting system. A named, commonly used set of components/connectors/configurations. Each component/connector has its own job.

Why spend a lot of time?

A requirement specification is the source for all future steps in the software life cycle.

Causes of late projects

1. Techniques of estimating are poorly developed 2. Confuse effort with progress, which hides the assumption that men and months are interchangeable 3. Software managers often lack the courteous stubbornness of Antoine's chef 4. Schedule progress is poorly monitored 5. When schedule slippage is recognized, it leads to adding manpower

How to create classes?

1. The set of nouns in the description of the problem (customer, assistant, account, etc) 2. The set of verbs in the description of the problem (call for assistant, check-in, check out, etc) 3. Go through some more detailed use cases to further flesh out the flow and objects necessary. 4. UI Mockups 5. A little bit of programming ? 6. Refer to, add to , and revise design as necessary.

Storyboard

A graphic display tool used to communicate the details of performance improvement activities.

Object-Oriented Design and UML

A software design method that models the characteristics of abstract or real objects using classes and objects. An object contains both data and methods. A class is a blueprint for making objects.

Pub-Sub

A system that publishes data but only to those systems that have subscribed to that data.

Abstraction

Abstractions are formed by removing irrelevant information and retaining/highlighting relevant information. Every design notation supports a certain kind of abstraction. Software engineering is all about describing, constructing, and elaborating abstractions/models.

Use Case Diagram

Actor, System Boundary, Use Case

Brooks' Law

Adding manpower to a late project makes the project later.

Evolution

All successful software evolves!!! Essential part of software development. Must be accommodated/planned as much as possible.

Layered

Can only communicate with the layer directly above or below themselves.

Peer-to-Peer

Connecting to multiple other systems to share/access the data in which you are interested and you can download different bits and pieces of that data from those other systems concurrently until you have the entire package of data.

Desired Software "ilities" (Qualities)/Non-functional requirements

Correctness, Reliability, Efficiency, Usability, Maintainability, Portability, Reusability, Interoperability, Robustness, Security, Scalabilty

Users of a Requirements Document

Customers, Developers, Managers, Testers, Documenters, Maintainers, System engineers, Marketing personnel

Relational Database Design

Design tables where data is stored and relationships between them

Association Relationships

Documents the communication that takes place between the use case and the actors that use the use case

Top Software Failure Causes

Lack of user input/involvement Incomplete requirements and specifications Changing requirements and specifications Lack of discipline in development processes Lack of methodical usage of metrics Lack of resources

Software Design Goals/Activities

Making system-wide decisions (Architecture, languages, libraries, platforms) Making lower-level decisions in an iterative manner (studying the problem, identifying solutions, creating abstractions)

Model-View Controller

Model = Bank Account View = ATM Display Controller = Rules

Three "Essential Ingredients" of Software Engineering

People + Processes + Tools

Inf 43 Recurring, fundamental principals

Rigor and Formality Separation of Concerns (modularity, divide and conquer, abstraction) Anticipation of Change Generality Incrementality

Use Case Purpose

Serve as a communication/understanding tool among diverse stakeholders Produce use cases in conjunction with other requirements engineering methods

User Interface Mockups

Shows examples of how the user interface/page would be designed.

Sketches

Sketching ideas are the first steps in the design process.

Approaches to Software Design

Software Architecture Functional decomposition Relational database design Object-oriented design and UML User interface design

No Silver Bullet

Software engineering is hard because of the essential difficulties of software (Complexity, Conformity, Changeability, Invisibility) Potential Silver Bullets: Buy vs Build, Requirements refinement/rapid prototyping, Incremental development, Great designers

What is Software Engineering?

Software engineering is the process of building a set of related models that represent the system-to-be.

Pipe-and-Filter

Stream of information which you can filter

Relationships: Inheritance

Such an inherited class is called a subclass of its parent class or super class. It is a mechanism for code reuse and to allow independent extensions of the original software via public classes and interfaces.

Software Architecture

The set of principal decisions about the system The blueprint for its construction and evolution A software architecture consists of components and connectors, arranged into configurations (that allow the system to achieve its functional and non-functional requirements) Architectural erosion happens when a system's prescriptive and descriptive architectures DO NOT match

Object-Oriented

This data model represents real-world entities with database objects. An object consists of attributes (characteristic describing an entity) and methods (operations or calculation) that can be performed on the object's data.

UML Class Diagrams

Used in decomposing a system into modules known as classes Typically used to: model domain concepts, create a detailed, object-oriented design of the code.

Requirements Definition

WHAT the software should do (without saying HOW it should do it)