Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
79 Cards in this Set
- Front
- Back
|
Design |
Iterative process through wc req and technical considerations are translated to a blueprint for construction |
|
|
Design |
Model that provides details about architecture, data structures, interfaces, and components |
|
|
Design Model |
|
|
|
Firmness - no bugs Commodity - suitable for purpose Delight - pleasurable experience |
A good software design must exhibit |
|
|
FURPS Functionality - features Usability - human factor, docu Reliability - accuracy, recover from errors Performance - processing speed, efficiency Supportability - maintainability |
Software Quality Attributes |
|
|
Procedural - method Data - object |
Abstraction design concept |
|
|
Architecture |
Overall software structure |
|
|
Structural - majoy sys components Extra-functional - capacity, reliability, security Family of related systems - ability to reuse architectural bldg blocks |
Properties of architecture |
|
|
Design pattern |
Proven design solution to a recurring problem |
|
|
Concern |
Feature or behavior that is specified as part of req model |
|
|
Separation of concerns |
A complex problem can be more easily handled if its subdivided into pieces that can be solved |
|
|
>Modularity Benefits: . Easily planned . Increments delivered . Changes more accomodated . Efficient testing debugging . Better long term maintainance |
Separation of Concerns Separation into right no. Of modules |
|
|
>Information hiding Benefits: . Reduces side effects . Communication through controlled interfaces . Discourages global data . Encapsulation . Higher quality software
|
Separation of concerns Hiding details of data structs and processing behind a module interface |
|
|
>Functional independence |
Separation of concern Each module addresses a specific subset of requirements and has simple interface |
|
|
[high] Cohesion |
Indicates relative functional strength of a module |
|
|
[low] coupling |
Indicates relative interdependence among modules |
|
|
>Stepwise refinement |
Separation of concerns Series of specified steps |
|
|
Aspects |
Separation of concernsModule that enables the concern to be implemented across other concerns it crosscut |
|
|
Cross-cutting concerns |
System characteristics that applies across many different requirements |
|
|
Refactoring |
Design/code simplification without changing its functions |
|
|
Redundancy Unused design elements Inefficient/ unnecessary algos Poorly constructed data structs Design failure to yield better design |
Why refactor? |
|
|
User interface classes |
Design classes Human-computer interaction |
|
|
Business domain classes |
Design classes Attributes and methods required to implement some element |
|
|
Process classes |
Design classes Lower level business abstractions to fully manage the business domain classes |
|
|
Persistent classes |
Data classes Represent data stores (database) |
|
|
System classes |
Design classes Control fcns that enable the sys to operate and communicated within and with outside world |
|
|
. Program-component level - data structs and associated algos . Application level - translation of data model to database . Business level - collection of data into data warehouse |
Data elements levels |
|
|
Application domain - for software to be built Requirements model elements - analysis classes and their relatio ships Architectural patterns and styles |
Architecture elements sources |
|
|
User interface UI External interfaces - other sys, devices , netowrks Internal interfaces - between components |
Interfaces elements |
|
|
.analyze effectiveness of design .consider alternatives early .reduce risks .provides representation for communication among stakeholders .graspable model of how the sys is structured |
Importance software architecture |
|
|
Blueprint metaphor Language metaphor Decision metaphor Literature metaphor |
Different views on architecture |
|
|
Architectural description |
Collection of work products that represents multiple views |
|
Data-centered architecture - promotes integrability |
Architectural style Data-centered architecture |
|
Data flow architecture A. Pipes and filters B. Batch sequential |
Archtiectural styles Data-flow architecture |
|
Substyles: A. Main program architecture B.remote procedure call arch |
Architectural style Call and return architecture |
|
|
Object oriented architecture |
Architectural styles Components of a system encapsulate data and operations Coordination bet components are done via message passing |
|
|
Architectural styles Layered architecture |
|
|
.economy - avoid unnecesary comlexity .visibility - decisions must be obvious .spacing - sufficient separation of concerns .symmetry - consistent and balanced attributes .emergence - self organized behavior and control |
Architectural considerations |
|
|
Archtectural patterns |
|
|
|
>Concurrecy - handle mutiple tasks in manner of parallelism (process mngmt, task scheduler) >Distrubution - components communicate with one another in distributed env (broker) >Persistence - data survives past executions (dbms, application lvl) |
Examples of architectual patterns |
|
|
Context |
External entities (sys, devices, ppl) that interact with the software and the nature of interaction |
|
|
Archetypes |
Important abstraction (class or pattern) that represents a pivotal element of sys behavior |
|
|
View layer - ui Control layer - directs flow of info to and from client browser Model layer - manages data, logic, app rules |
Web apps arch design MVC |
|
|
Agility and architecture |
|
|
Component |
A modular, deployable, replaceable part of a system that encapsulates implementation and exposes set of interfaces |
|
|
Set of collaborating classes |
A component contains? |
|
|
. Open closed principle (ocp) . Liskov substitution princ (lsp) . Dependency inversion princ (dip) . Interface segregation princ (isp) . Release reuse equivalency princ (rep) . Common closure princ (ccp) . Commom reuse princ (crp) |
Basic design principles |
|
|
Cohesion |
single mindedness of a component |
|
|
. Functional - a module performs one and only one computation . Layer - higher layer accesses a service of a lower layer . Communication - all operations that access the same data are defined within one class |
Types of cohesion |
|
|
Coupling |
Degree of connectedness between components |
|
|
. Content - when a component sneakily modifies data to another component . Control - occurs when A() invokes B() and passes a control flag to B . External coupling - when a component communicates with infrastracture components (OS, DB) |
Categories of coupling |
|
|
Design patterns |
Way of resuing abstract knowledge about a problem and its solution |
|
|
Pattern name Problem descp Solution descp Consequences |
Pattern elements |
|
|
Observer pattern - tell several obj that the state of other obj has changed Iterator pattern - provide standard way of accessing the elemnts in a coolection Decorator pattern - allow the possibility of extending the functionality of an existing xlass at runtime |
Design problems |
|
|
. Creational - creation, composition, repsresentation of obj . Sttuctural - how obj are organized and integrated . Behavioral - communication bet obj |
Gang of Four patterns |
|
|
. Abstraction level . Object level . Component level . System level |
Levels of reuse |
|
|
Singleton pattern |
Pattern that ensure a class has only one instance, and provide a global point of access to it |
|
|
Lazy instantiation Prob: 2 instances of singleton Sol: synchronization or eager instantiation |
Singleton instance is Only created when needed |
|
|
Decorator pattern Aka Wrapper |
Pattern that attach additional responsibilities to an obj dynamically. Provides flexible alternative to subclassing |
|
|
Iterator pattern Aka cursor |
Povide a way to access an aggregate obj sequrntially without exposing its internal structure |
|
|
Aggrragte object Or container or collection Ex. Linked list or hash table |
Objevt that cointains other objevts for purpose of groupinng those obj as a unit |
|
|
. Want single instance of class only and dont want addtnl instances . Addntl prpperties for ex GUI want scrollbar and border . Want to traverse a list without exposing internal ****. Different traversals and multiple |
Motvation for single ton, decorator, iiterator |
|
|
Robust iterator |
Iterator that allows insertions and deltiond eithout affecting the trsversal. |
|
|
Hyperprpductivity |
400% higher velocity than average waterfall team velocity |
|
|
Velocity |
Sum of all story points completed per sprint |
|
|
Capacity |
Sum of all points spent per sprint (story points or hours) |
|
|
Focus factor |
Velocity over capacity |
|
|
Adopted work |
Sum of pulled work from another sprint |
|
|
Found work |
Reported work minus original estimate |
|
|
Sum of original estimate divided by sum of original, adopted, found |
Accuracy of commitment |
|
|
1. Actual vs committed stories - ability to predict their capabilities 2. Technical debt - problems issued delivered (# of bugs) 3. Team velocity consistency - (+/-)10% 4. Restrispective process improvement - teams abilit to improve its process (#of improvement items) 5. Qualitative measures - surveys, observation discussion, feedbacks |
Other metrics |
|
|
. Reactive - firefightong, reacts to risks when they occur. Lead to crisis managmt when not addressed . Proactive - begins before technical work is initiated. Contingency plan |
Risk management strategies |
|
|
. Project risks - threaten project sched or cost. Budget, sched, staff prpblems . technical risks - threaten quality and timeliness. Design, implementation, testing probs . Business risks - threaten the viability of softwarr and often jeopardize the prog |
Types of risks |
|
|
. Mantain global perspective . Take a forward-looking view . Encourage open communication . Integrate . Emphasize a continuous process . Develop a shared prod vision . Encourage teamwork |
Risk management principles |
|
|
Identify analyze plan track control |
Risk mngmt model |
|
Performance risk - unceryaitny to meet reqs Cost risk - product budget be maintaned Support risk - resultant software is easy to correct, adapt Schedule risk - product delivered on time |
Risk components |
|
|
. Prpduct size . Business impact . Stakeholder characteristics . Process definition . Development environment . Techbokogy to be built . Staff size and experience |
Risk identification |
|
|
Risk projection aka Risk estimation Rates in two ways: 1. Probability of risk 2. Consequence of risk |
Risk projectiob |
|
|
Mitigation - how can we avoid risk Monitoring - factors to track to know if risks is more or less likely Management - what contingency plan if happen |
RMMM |
