CSS 360 Quiz 2

Software Architecture

"the set of principal design decisions about the system" high level - no specify connectors

Scenario include

- A description of the starting situation; - A description of the normal flow of events; - A description of what can go wrong; - Information about other concurrent activities; - A description of the state when the scenario finishes.

Airport 95 Case Study

- BAE Automated systems - multiple contractors with diff aspects of project SDLC - rapid prototyping or rapid application development

Shrink-Wrap Software Key Markets

- Consumer - Vertical Market - Entertainment

Maintainability qualities

- Corrective - removal of residual errors - Adaptive - adjusting the software to changes in the environment - Perfective - changing the software to improve some of its qualities or add new features - legacy software/ reverse engineering

Custom Development Customer

- Customers are management sponsoring the system development - goal: increase productivity or reduce costs of org. automate or improve biz process

Anticipation of Change

- Software changes during the course of its life - unique to software Reasons for Change - a limited understanding of req. when software was dev. - environmental - software product and software process - Anticipation of change can save $$ over the life of the product

Main pieces of scenario

- actor - pre/post conditions - normal flow with numbered steps

Scrum- Story Points

- agile - user stories -combo of size and complexity of work -unitless but num relevant estimation 10 pt 2x as 5pt

Airport 95 Background

- automated baggage system - baggage handling system enables aircraft turnaround time of 35 min even if gates > mile terminal - took too long with tug-and-cart and belt conveyors

Airport 95 Challenges

- cars propelled by linear induction motors - car-on-track system : must respond in real time - customers : major change in req. and major redesign - contractor infight - testing show more problems - system no detect when telecarts full - conveyor belts/telecarts not synch

Examples of abstraction

- comments describing a method - user interface

Open Source Software

- community SW dev - collab paid/unpaid -source of SW for custom, embedded, or webservice dev

Estimation accuracy

- degree to which planer properly est. size of product to be built - ability to translate size of estimate to human effort, calendar time, and $$ - degree to which project plan reflects abilities of software team - stability of product req. & environ supports SW eng

Layered

- each layer relies on facilities/services of layer below

Requirements Statements

- easy read/understand - avoid ambiguity and terminology - testable - organized for appropriate audience - numbered

Internet and Web Service

- enable a service sell internet -service often times 1 specific functionality - combo shrink-wrap & custom dev. - external customers benefit from using a service - SW supporting service is usually custom in-house dev to serve a specific purpose

Information Hiding Advantages

- enables change can change internals (input/output the same u can swap one black box for another) - delay implementation details - related modules can be dev dep on modules -easier to maintain since the change is localized to a module

Singleton Design Pattern

- ensure class has only 1 instance and provide global pt. of access - use when imp for some classes to exactly have 1 instance (1 printer spooler & 1 op sys)

Embedded Development

- expensive per line of code - critical systems - high assurance $$ and formal methods - safety and reliability imp impossible/impractical to upgrade sw

Consumer Mass Market

- general or consumer interest - office software, multimedia, common utilities, home accounting/taxes - allow user to accomplish a task

Embedded Systems Users

- indirect nature of SW - seldom $$ the device b/c SW - marketing & systems engineering personal = customer/user

Tools of the Tradee

- information hiding - determine usage patterns - anticipate change - design for generality - incrementality - design for product families - use req. or stories

System Reliability

- key property -Depends on all components of the system and their interdependencies and interrelationships. Reliability is difficult to predict because of combinatorial possibilities

Entertainment: Games

- mass market/ ephemeral - multidiscip. dev req, art & eng. - movie & tv prod

Object Points

- no connection to OO prog Types - screens, reports, 3GL components Complexity - simple,medium, difficult

Open Source Development

- no formal notion customer/dev - contract to tech support - sponsoring org - responsible version/quality control - take, adapt or leave -req. certain level of sophistication to customize or adapt

Incrementality

- process that proceeds in stepwise fashion - application - id useful early subsets that can be released to customers to get early feedback - some SDLC have it

Metrics

- provide quantitative info about quality & productivity of SW projects and processes - captured as estimates during process and postmortem statistics

Scenario

- real life example of how system can be used - good for adding details to outline description

Deliverable

- req. doc contract b/t - engineer and customers

How can requirements be expressed?

- requirements statements - scenarios - models

Open-Closed Principle

- should be open for extension but closed for modification - inheritance - An advantage of this principle is that it maintains data in one place

Shrink-Wrap Software

- software package sold as a product for profit - instore, downloadable, sub based online app

Abstraction

- special case of sep of concerns - It is a process where we identify the important aspects of a phenomenon and ignore its details

Information Hiding

- special instance of abstraction - modules as opaque "black boxes" with inputs, outputs, and purpose.

Shrink-Wrap Development

- stability - usability - installation & support - cost of maintenance & fixing errors $$$ - income directly related to new versions and upgrades

Software Architecture Advantages

- stakeholder communication dev follow blueprint when writing sw - System analysis analyzing design detect flaw in code b4 written - Large-case reuse - use existing template & id parts of design reuse existing software or third-party components

Shrink-Wrap Customers

- statistical models from market surveys - marketing rep external customer to dev staff - custom sw alienate broader customers

Systems Challenges

- systems multidisciplinary team to develop , operate, maintain - size and complexity of large systems add to problem to be solved - systems are usually required to last for years in a changing environment

Why planning poker works?

- those who do the work est the work - estimators req. to justify estimates - focuses most estimates w/in approximate one order of magnitude - combine individual estimates through group discussion leading to better estimates - emp rel rather than abs estimating - estimates are constrained to a set of values - everyone opinion heard - quick and fun

KLOC

- thousands of lines of code

When to use Adapter?

- use existing class and interface not match one u need - create reusable class co-op w/ unrelated/unforseen classes - don't have necessarily have compatible interfaces

UI Patterns

- whole UI - page layout - forms and input - tables - direct data manipulation - navigation - search - page elements - e-commerce

Anticipate Change

- wrap items likely to change w/in modules - design module interfaces to be insensitive to change why? - limit effects of unanticipated system mod

COCOMO

-Measure effort based on developing all software from scratch •Lines of code

COCOMO II

-Take into account recent developments (code reuse, team experience, platform, distributed development, etc.) •Object points, lines of code

Module Design

-What is the internal design of this component -What is the functionality--How does it work?

Sequence Diagrams (scenarios as models)

-may be used to add detail to use-cases by showing the sequence of event processing in the system - UML

Requirement Analysis

1. Coming up with a project plan, revising it as needed. Plans could include budgets, schedules, and resources 2. Risk management 3. Plan for the next phase

Cost estimation

1. Each estimator a deck of cards w/ valid estimate 2. customer/prod owner read story and brief discuss 3. Each estimator select card that's her or her estimate 4. Cards are turned over so all can see them 5. Discuss diff 6. Re-estimate until estimates converge

Cost Estimation Advantages

1. force relative estimating 2. Focuses us on estimating size not duration 3. Puts estimate in units we can add

Architectural Design

1.partitioning of a software system into separate modules (components) 2.How the components communicate or interact (connectors) 3.How they are laid out and that is called configuration

What does architectural design require?

1.purpose of each component 2.interfaces of each component -Interfaces are ways the method of a component can be accessed or used by other components - Id the interfaces as complete as possible 3.architectural diagram- revise and refine it; imp if building a large system last long time 4. use the fundamental sw eng principles

Usability

A software system is usable—or userfriendly- if human users find it easy to use - subjective - human interface dependent - Embedded systems - Ease by which the system can be adapted to the environment - Human factors, usability engineering

verfiability

A software system is verifiable if its properties can be verified easily (e.g. performance or correctness) - often internal -

Interoperability

Ability of a system to coexist and cooperate with other systems Example: ability to incorporate a chart produced by a graphics package into a spreadsheet Technique: Wrappers and Open APIs

Seperation of Concerns

Allows us to deal with different aspects of a problem, so that we can concentrate on each separately - time - qualities - views

Performance

An external quality based on user requirements Affects usability and scalability

Connectors

Communication Units

Basic Software Architecture Elements

Components are boxes with double outlines. Connectors are boxes with single outline. Interfaces (exposed entry & exit points for components and connectors) Links Configuration (topology)

Components

Computational Units

CASE Tools

Computer Aided Software Engineering tools. - They support software professionals by automating/assisting with the use of SE methods.

When is software architecture created?

Design Phase

Workflow patterns

Flow of events to address a recurring business process -Control -Resource -Data -Exception Handling

Levels of Design

High level - architecture Low Level - handed to developers to code

principal

How one defines "principal" depends on what the development team define as the system goals

Why KLOC not a good metric?

Instead of counting lines of code, one can count function points which counts the number of data structures used. This considers the number of input types, output types, inquiries (e.g. queries), logical internal files (e.g. index), and interfaces. Another metric is the number of classes or the number of function points per class.

Observer

Intent: def a one-to-many dep b/t objects so that when one object changes state all dep are notified & updated auto - dep/publish subscribe Use - keep classes consistent w/o making objects tightly coupled

System example

Intranet Software- -the Intranet portal, front-end and backend (may have a database) Hardware- Server and Client machines Infrastructure - has connections to other systems People- admin and users

Use Requirements Spec/User Stories

N - modules/classes V - methods Adjective- properties/attributes/member variables - can be exceptions - to id design elements

External reliability factors

Physical environment - weather, temperature ,humidity operations - policies, procedures, documentation business and regulatory environment - enforcement, auditing, ethics

Requirement Management Plan

Plan for: - requirement id - a change management process - traceability policies - CASE tool support

Sense-Compute-Control

React to stimuli Typical uses -Real-time systems Caveat -Highly subject to environ conditions -Hardware malfunction (e.g. in sensors) may not be detected and system can enter into an error state

Knowledge areas of SWEBOK

SW design, SW implementation/design, SW testing, SW maintainence

How does Layering support separation between layers?

Separation: b/t layers b/c each layer provides own set of services Independence: b/c pull one layer and sub another w same interface w/o affecting other layer

Control-Flow Pattern

Sequence- indicates linearly 1 step @ a time Parallel Split- indicates that work can split 2 branches & work in parallel Synchronization- can occur any order, one or both work branches of work meet in the AND node

Custom or Shrink-Wrap

Shrink Wrap Because only have to think of scenarios provided by the company, don't have to generalize

SWEBOK

Software Engineering Body of Knowledge •Describes the knowledge areas that comprise all of the concepts, methods, and practices related to software engineering

Portability

Software is portable if it can run in different environments Common technique is to isolate the dependencies on the operating system into a few isolated modules

Maintainability

Software maintenance - modifications to a software system after initial release - if the software allows us to make these changes - 60% software costs maintenance

Understandability

Software system can be understood - Internally - for software maintenance - Program understanding task - Externally - predictable behavior, related to usability

Systems vs. Software Engineering

Systems -deals with all aspects of creating and maintaining a complete system—hardware, software, infrastructure, operations, and related business processes SW E -concentrates on the software component of the larger system

Traceability Matrix

Technique to manage traceability links between requirements or between requirements and other artifacts (design, source code, etc) Notation at the intersection indicates a link

Requirements Management

The process of managing changing requirements during the requirements engineering process and system development

Common Module levels

These are systems, subsystems, components/services, classes and functions As you go from top to bottom, the size and scale goes down. As you go from bottom to top, then you move toward the system's purpose

object-oriented programming

Typical uses -App where dev want a close correspondence to the real world -Dynamic data structures Caveat -If use in a distributed setting, will req extensive middleware -Relatively inefficient for high perf app

MVAC typical uses/caveat

Typical uses -Graphical user interfaces -Multiple ways to view or manipulate the data Caveat -If interactions between data model and controller are simple, may have more overhead

Client- Server

Typical uses -Where centralized data or centralized processing is needed •Usually biz app Caveat - not work well with a limited bandwidth & many client connections

Reusability

Use a software product, perhaps with minor changes, to build another product granularity: - Application - Component - seems to be the dominant - Routines other software artifacts and software products

bottom-up design

When dealing with the details of each module in isolation

top-down design

When dealing with the overall characteristics of all modules and their relationships to integrate them into a coherent system

Modularity

When you are designing software, you can break it down into pieces call modules, which are doable building blocks - resusabilty

Design for Generality/Incrementality

Why? - increase reusability

Correctness

a program is functionally correct if it behaves according to its stated functional specifications (an absolute quality)

Robustness

a program is robust if it behaves "reasonably" even in circumstances that were not anticipated in the requirements specification - how program behaves when incorrect data input or hardware malfunction

Reliability

a software is reliable if a user can depend on it - The probability that the software will operate as expected over a specified time interval - Possible to have an "incorrect" system that is still reliable Relative quality

Use- Cases (scenarios as models)

are scenario based techniques which identify the actors in an interaction and which describe the interaction itself A set of use-cases should describe all the possible interactions with the system - UML

Why is Software Architecture important?

because it affects the performance, robustness, distributability of a system Functional req. depend on components Non-functional requirements - largely depend on the system architecture. - the software architecture affects the software qualities of the system

Generality

behind generality is you create general purpose code, not simply for the task at hand. Creating general purpose code, however, can take more time than and is a bit more difficult. If you do apply generality to a module, this module can be reused throughout the system

What analogies can we draw from building architectures?

building architecture - customer req. purpose of building functional/nonfunctional req. blueprint - same for software as implementation guided by design

Adapter

converts the interfaces of a class to another interface the clients expect. It is also known as "wrappers". It is similar to electrical adapters

OSS vs FOSS

does not mean free software—you have to abide by the license, else you and your orgnaizaton may be held liable for violating the license

System Reliability Factors

hardware/infrastructure - fans, hard drive, false connections software - incorrect calculations - system faults operator/human error - one part is working the entire system not work

Upper CASE Tools

help documenting and modeling the problem and its solution(s), so these are tools that assist with capturing requirements, modeling, and design such as the tools you see on the screen. - support top phases waterfall - IBM, Visio Professionalism, Rhapsody

Software Principle

high cohesion and low coupling

Architectural Styles

is a collection of architectural design decisions that are applicable to a recurring design problem

System

is a set of interdependent and interrelated components used to accomplish a task or objective. Components may be Software, Hardware, Infrastructure, People

Model-View-Controller (MVC)

is a style or a pattern used when you want to have diff views on the data, or diff ways to control the data. objective- promote sep b/t model and data store Controller- control app behavior & the view which displays the data.

Traceability

is concerned with the relationships between requirements, their sources and the system design - det if req. is met

Software Process

is the business process of creating, deploying, and maintaining software

Coupling

is the strength of relationship between different modules

Cohesion

is the strength of relationship between elements within a module

Architectural Design

is understanding how a system should be organized and designing the overall structure of that system

Agile Process and Architectural Design

occurs early stage of development. agile - current req. & not future - incremental dev of arch - usually not successful

When is layered used?

operating systems and network protocols caveat: that strict virtual machines can be inefficient (many layers hard to move top to bottom)

Cost Estimation

primary cost- ppl/ how many engineers working on project (man-days, man-weeks)

Middleware

provides extensions to operating systems. OMG Cobra/DCE Microsoft COM/ActiveX/.Net

Control-Flow Pattern

sequence, synchronization, partial split

Lower Case tool

support activities in the lower phases of the waterfall lifecycle, such as coding, testing, and maintenance. You probably used one of these tools in your programming class. - eclipse, visual studio, github

Design Pattern

•A description of communicating objects and classes that are customized to solve a general design problem in a particular context

Design for Product Families

•A system is typically used in more than one setting -Different countries •Different languages •Different customs •Different $$ -Different hardware/software platforms •Why? -To enhance applicability -To keep your company$$

Interface

•Abstractions of the functionality of a component -Define the set of services that a component requires or provides -Requires: other components use or supply these services Provides: components themselves implement the service - contract

System Models

•Classify subsystems and components based on functionality, location, or other factors

What is Design?

•Creation of a blueprint that solves the problem posed by analysis •Involves the selection of key technologies and/or approaches •Balances realities and practicalities to identify a feasible solution

Assessment

•Current cost estimation models -Based on existing project data, but... •projects vary from and within a domain (past projects vs new projects) -Hard to estimate lines of code •Tip -Collect project information -Can create better estimates over time

Vertical Market

•Directly improves key processes of a specific business such as: - Specialty POS - CASE tools Bundled systems complete with software & hardware

Repository / Blackboard

•Good way to share large amounts of data among interacting components around agreed data model Typical Uses -Want components to interact via changes to the centralized data Caveat -If the data model changes, have to reflect the change to all the components

Interfaces and Software Design

•Interfaces separate concerns -Interfaces modularize a system -Interfaces abstract implementation details •With respect to what is provided •With respect to what is required •(Good) interfaces anticipate change

Applying Information Hiding

•One module "hides secret information" from other modules -Data representations -Algorithms -Sequencing of processing •Why? -To create a clean separation of concerns

Embedded Software

•Software embedded in a larger hardware-based system (or device) •Users interact with the software indirectly •Large numbers of embedded software - functionality provided by system as a whole - sw role assist digital processing w/in electronic domain - req. real time systems interact with external environ

Real Time Systems

•Systems that direct interact with the environment through sensors and actuators •Systems that require scheduling of tasks

Main Program and Subroutines

•Typical uses -Small programs •Caveat -Large applications - will not scale

Custom Development

•Unique software created for a particular customer and problem •Performed by Internal IT / MIS / IS

Determine Usage Patterns

•Usage patterns are incredible sources of information -Common tasks often can be placed into a single interface method •Specific combinations of method invocations •Specific iterations over a single method Why? -To refine the interface of a module -To apply generality

Cost Drivers

•attributes that affect productivity -E.g. database size, analyst capability, documentation needs

Cloud Computing

•is an approach to the provision of computer services where applications run remotely on the 'cloud'. - no hardware or software brought - pay according to use -cost effective small org. who lack resources to have their IT team