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
