Software Engineering Notes PDF

Sept 9 - Intro to Software Eng: Software Eng Doing software right - have a systematic approach Develop products within a specified budget and time Software Definitions ○ Instructions - When executed provides desired features, functions, and performance ○ Data Structures - Enables programs to manipulate information ○ Documentation - Describes operation and use of programs Nature of Software ○ Software is developed/engineered Types of software ○ System: Collection of programs written to service other programs ○ Applications: Stand-alone programs that solve specific business need ○ Engineering/Scientific: Broad array of ‘number-crunching’/data science programs ○ Embedded: Resides within a product/system and used to implement and control features and functions for end user and system itself ○ Product-line: Composed of reusable components and designed to provide specific capabilities for use by many different customers ○ Web/mobile Web: Software-as-a-service that is delivered through web browser Mobile: Application software for mobile devices ○ Artificial Intelligence: Makes use of heuristics to solve complex problems that aren’t amenable to regular computation How to Make Good Software Software Eng Layers ○ Quality Focus Commitment to quality Commits to a culture of continuous improvement and focus on quality ○ Process Defines framework for effective and timely delivery Enables control of software projects ○ Methods Technical how-tos for building software ○ Tools Aid in automation and support of software eng processes and methods Process Framework: Process framework establishes foundation for complete process Consists of umbrella activities that complement framework activities Definitions ○ Process - Collection of activities, actions, and tasks ○ Activity - Broad objective ○ Action - Set of tasks ○ Tasks - Small, well-defined objectives 5 Key Activities ○ Communication - Customers/stakeholders to under objectives and identify needs and wants ○ Planning - Technical tasks, risks, resources, work products, and work schedule ○ Modeling - Software requirements and design that will achieve those requirements ○ Construction - Code generation and testing ○ Deployment - Software is delivered to customer and provides feedback ○ Doesn’t happen in order Umbrella Activities - Applied throughout a project: Software project tracking and control Risk management Software quality assurance Technical review Measurement Software configuration management Reusability management Work product preparation and production Defining Framework Activities: Identifying Task Set ○ Defines the actual work ○ Must accommodate the needs of the project and characteristics of the team ○ Defined by creating several lists List of tasks to be accomplished List of work products to be produced List of quality assurance filters to be applied Process Flows ○ Evolutionary Process Flow - Keep iterating through 5 key processes till the product is done ○ Iterative Process Flows - Throughout the process, communication is a constant ○ Parallel - Modelling is done after planning and communication so 2 models are made Process Model A combination of process flows Prescriptive Process Models ○ Orderly approach to software ○ Is this appropriate for an environment of change? Waterfall ○ A systematic sequential approach to development ○ Customer specify requirements, then planning, modeling, construction, and deployment occurs ○ Ongoing support and maintenance of complete software proceeds from there ○ Simplest ○ Pros: Easy to understand and plan. Works well with small project. Analysis and testing a straight forward ○ Cons: Doesn’t accommodate change well ○ Testing occurs late ○ Customer approval is at the end V-Model ○ Variation of waterfall ○ Attempt to capture the relationship between quality assurance actions and actions associated with communication, modeling, and early construction ○ Once code to generated, team moves up the V, carrying out series of test ○ Pros: Same as waterfall. Good way of visualizing how verification and validation action are applied to earlier work ○ Cons: No difference between V and waterfall. Same as waterfall Prototyping ○ Prototyping begins with communication, collecting initial requirements, and outlining areas where further definition is necessary ○ Prototyping iteration is planned, with quick models and designs, focusing on aspects of software visible to end users ○ Design work leads to construction of prototype ○ Deployed and evaluated by stakeholders, who provide feedback to refine design ○ Pros: Reduced impact of requirement changes. Customers are involved early and often. Works well for small projects. Reduced likelihood of product rejection ○ Cons: Customer involvement may cause delays. Temptation to release a prototype. Work lost in a throwaway prototype. Hard to plan and manage. Spiral ○ Evolutionary approach that couples iterative nature of prototyping with controlled and systematic aspect of waterfall ○ Risk-driven approach in which each cycle through model incrementally grows software degree of definition and implementation while decreasing degree of risk ○ Prototyping becomes risk reduction mechanism that moves software closer to ideal form(becoming more finished and complex) each cycle ○ Pros: Continuous customer involvement. Development risks are managed. Suitable for large, complex projects. Works well for extensible products. ○ Cons: Risk analysis failure can doom project. Project may be hard to manage. Requires expert development team. Unified ○ Unified Process is a ‘use-case driven, architecture-centric, iterative and incremental’ software process closely aligned with Unified Modeling Language. ○ Consist of number of phases that map to generic framework activities and tries to overlap them Inception: Communication and planning Elaboration: Planning and modeling Construction: Early-mid construction Transition: Late construction and deployment Production: Outgoing use of software is monitored, supported provided, defect reporters are submitted to shape next update of product ○ Iterative in nature ○ Pros: Quality documentation emphasized. Continuous customer involvement. Accommodated requirements changes. Works well for maintenance projects. ○ Cons: Use cases aren’t always precise. Might not need to use docs after software is developed. Tricky software increment integration. Overlapping phases can cause problems. Requires experienced dev team. Overall ○ There are many more prescriptive process models ○ All have issues with change ○ Still appropriate for well understood projects/large teams Sept 16 - Unified Modeling Language: What is UML: Unified Modeling Language: ○ Unified - Brings together techniques and notations for design or collection of diagrams ○ Modeling - Software system and its design at high level of abstraction ○ Language - Provides means to communicate design in logical, consistent and understandable fashion Goals: ○ Enable modeling of object-oriented designs ○ Visually depict aspects of overall design of solution ○ Provide extensibility and specialization mechanisms to extend core concepts ○ Be independent of particular programming language/development process ○ Support higher-level development concepts (collaborations, frameworks, patterns, and components) Diagram Types ○ Behaviour - Dynamic view, focuses on runtime behaviour, interactions, and processes w/in system ○ Structure - Static view, focuses on components, relationship and organization Uses ○ Sketch - Share rough ideas/alternatives ○ Blueprint - Detailed description of system w/ enough detail that all major design decision are covered and could be implemented ○ Programming language - Can generate code based on detailed UML diagrams Directions ○ Forward Engineering - Create models, plans, and blueprints for system not yet created ○ Reverse Engineering - Working backwards from existing system/code based to create UML diagrams to explain/document them Class Diagrams: Definition ○ Describes types of objects in system and kinds of static relationships between them ○ Shows attributes(fields) and operations(methods) of a class ○ Can be used for requirements engineering and design modeling Parts of Diagram ○ Class Name ○ Attributes/Fields ○ Operations/Methods Relationships ○ Class diagrams use arrows to denote relationship between classes ○ - - -> : Dependency ○ → : Association - Structural relationship that represents how 2 entities are linked/connected. If 2 classes in the model need to communicate, there must be a link(can be represented by association). Points in direction of navigability ○ —♦ : Composition ○ —-Δ : Generalization - Inheritance relationship, connects specialized element w/ generalized element. Arrow points to parent object ○ - - -Δ : Realization - Connects 2 elements in which one describes responsibility not implemented and other implements them. Relationships exist in the case of interfaces. Arrow points to parent object Keywords - To refine meaning of model element Activity Diagrams: Description ○ Provides graphical representation of flow of interaction ○ Represent how system reacts to internal events ○ Adds additional detail not mentioned(implied) by use case ○ Similar to flowchart except activity diagram can show concurrent flows Diagram parts ○ Initial Node - Start of program ○ Action Node - Node with actions ○ Final Node - Where activity is done ○ Decision Node - Decision is being made and goes down a branch flow ○ Flow - Shows which actions result in other actions Notation ○ Fork - Denotes all flow splits and all branches are taken (concurrency) ○ Join - Denotes that multiple flows are rejoined. Waits until all incoming flows have reached Swimlane Diagrams ○ Useful variation of activity diagrams that allows representation of the flow of activities ○ Indicates which actor/analysis class has responsibility for the action ○ Responsibilities are represented as parallel segments Use Case Diagrams: Definition ○ Technique for capturing the functional requirements of a system ○ Describe interactions between users of system and system itself ○ Expressed in narrative form (fixed template) ○ Users/external systems referred as actors ○ Actors role that user/external system plays in use case Parts of Diagram ○ Actors represented by stick figures/boxes with label ○ Use cases displayed as ovals and placed in rectangle that represents boundaries of system ○ Relationships Association - Actor communication with system Generalizes - Denotes actor also inherit all use cases of another actor Includes - Denotes use cases is made up of smaller subcases and would be incomplete w/out them Extends - Denotes that use cases may optionally make use of this use case, can be used w/o them Sept 17 - Agility and Process Issues with Prescriptive Process Models Real world is fluid (Requirement change, market conditions, end-user needs evolve, new competitive threats emerge, etc) Too rigid and structured to deal with change effectively Agile methods aim to reduce cost of change and add human element to traditional models What is Agility Effective (rapid+adaptive) response to change Effective communication among all stakeholders Drawing on customer onto team Organizing team so that it’s in control of work performed Rapic, incremental delivery of software Key Assumptions: ○ Difficult to predict which software requirements will change ○ Some activities should be done in tandem ○ Analysis, design, construction, and testing aren’t predictable Need adaptability to deal with uncertainty Agile Process Answer lies in process adaptability Process must adapt incrementally based on customer feedback Delivers multiple software increments as executable prototypes in short time periods Prototypes act as catalyst for customer feedback Agile Teams Tends to work best for small team Key traits for ppl on agile team ○ Competence ○ Common focus ○ Collaboration ○ Decision-making ability ○ Fuzzy problem-solving ability ○ Mutual trust and respect ○ Self-organization ○ Discipline Cost of Agile Process Can seem chaotic and uncontrolled Ppl on team don’t have right trait or those leading team lack discipline, process can eventually evolve to lack of process Agility Principles Highest priority is to satisfy customer through early and continuous delivery of software Welcome changing requirements. Agile processes harness change for customer competitive advantage Deliver working software frequently Business ppl and devs must work together daily Build projects around motivated individuals. Trust them to get job done Most efficient and effective method of conveying info and w/in dev team is face-to-face conversation Working software is primary measure of progress Agile processes promote sustainable development. Sponsors, devs, and users should maintain constant pace indefinitely Continuous attention to technical excellence and good design enhances agility Simplicity - art of maximizing amount of work not done Best architectures, requirements, and design emerge from self-organizing teams At regular intervals, team reflects on how to become more effective, then tunes/adjusts behaviour accordingly Scrum Framework activities are: requirements, analysis, design, evolution, and delivery Tasks in each framework activity take place in short time box called sprint Small teams consist of: ○ Product owner - Project stakeholder Responsible for maximizing value of product resulting from work of dev team Key responsibilities - Managing product backlog ○ Scrum master - Facilitator to all members of scrum team Runs daily scrum meetings Removes objective identified by team members Deal with product owner ○ Dev team (3-6ppl) Create software increments Decide when increment is done and when to present to product owner Scrum Artifacts ○ Product Backlog Prioritized list of product requirements Items added go backlog at any time (with approval of owner and dev team) Product owner orders items in product backlog ○ Sprint Backlog Subset of product backlog Items to be completed during current sprint Items can’t be added after the sprint starts (unless cancelled and restarted) ○ Code Increment Union of all product backlog items completed in previous sprints and all sprint backlog items to be completed in current sprint Scrum Meetings ○ Backlog Refinement Meeting Devs work w/ product owner and stakeholders to create product backlog Ranked by importance of product owner’s business needs ○ Sprint Planning Meeting Held b4 each sprint Product owner gives goals for next increment Scrum master and dev team select items for Sprint backlog ○ Daily Scrum Meeting Start of the day, team members synchronize activities and plan work day (15 min max) Purpose is to ask What have you done since last meeting What obstacles are you encountering What do you plan to accomplish by next meeting Scrum master leads meeting and clears obstacles by next meeting Not problem-solving meetings ○ Sprint Review At end of sprint Prototype demos are delivered to stakeholder for approval/rejection If not accepted, stakeholder provide feedback New features added/removed from product backlog ○ Sprint Retrospective After sprint, team considers what went well and what need improvement Discuss What went well What could be improved What team will commit to improving in next sprint Meeting run by Scrum master Pros ○ Product sets priorities ○ Team owns decision making ○ Documentation is light ○ Supports frequent updating Cons ○ Difficult to control cost of changes ○ May not be suitable for large teams ○ Requires expert team members Extreme Programming(XP) Framework Consist of 4 framework activities ○ Planning Begins with creation of user stories Team assesses each story and assign cost(dev time) Stories grouped together for deliverable increment Delivery date of the increment is decided After 1st increment, project velocity is computed and used to help define subsequent delivery dates for other increments ○ Design Follows KIS Encourages use of CRC cards(Class-responsibility collaborator) as mechanism to think about software in object-oriented context CRC cards only work product of design activity Immediate prototype creation is recommended for difficult design problems to lower risk Encourages refactoring to enable design both b4 and after coding commences (improve quality and simplicity of code) ○ Coding Series of unit test created b4 coding Unit tests cover each of user stories that will be included in current release Test-driven Development Encourages use of pair-programming (2 ppl working together at workstation for real-time problem solving and quality assurance) Pair programming styles Unstructured - Devs trade off who take lead and should discuss about code Driver/Navigator - One dev set architectural/strategic direction and other implements Ping-pong - Shifts rapidly between 2 devs ○ Testing All unit test are executed daily, preferably in automated fashion “Acceptance tests” are defined by customer and executed to assess customer visible functionality Pros ○ Emphasizes customer involvement ○ Establishes rational plans and schedules ○ High dev commitment to project ○ Reduced likelihood of product rejection Cons ○ Temptation to “ship” prototype ○ Requires frequent meetings about increasing costs ○ Allows for excessive changes ○ Depends on highly skilled team members Kanban Framework Lean methodology for improving any process/workflow Focuses on change management and service delivery Kanban board shows all project’s tasks, their current statuses and help track their progress over time Limit amount of work in progress at any given time Tasks generally move from left-to-right in the board ○ Backlog - Tasks waiting to be selected for development ○ To Do - Tasks selected for development that are waiting to be worked on ○ In Progress - Tasks that are currently assigned and are being worked on ○ Done - Tasks that have been completed Approach is flexible and so organizations will frequently have own columns and conventions for own business needs Daily meeting called ‘walking the board’ ○ Team identifies any items missing from board that are being worked on ○ Team tries to advance any items they can to ‘done’ ○ Goal is to advance high value/risk items first Kanban can be easily combined/used with other agile development practices Pros ○ Lower budget and time requirements ○ Allows early product delivery ○ Process policies written down ○ Continuous process improvement Cons ○ Team collaboration skills determine success ○ Poor business analysis can doom project ○ Flexibility can cause devs to lose focus ○ Developer reluctance to use measurement Dev OPs Attempts to apply agile and lean development principles actress entire software supply chain Involves several stages: ○ Continuous Development - Deliverables broken down and developed in multiple sprints ○ Continuous testing - Automated testing tools used prior to integration ○ Continuous integration - Code pieces w/ new functionality added to existing running code ○ Continuous deployment - Integrated code is deployed to the production environment ○ Continuous monitoring - Team operations staff members proactively monitor software performance in the production environment Pros ○ Reduced time to code deployment ○ Team has devs and operations staff ○ Team has end-to-end project ownership ○ Proactive monitoring of deployed product Cons ○ Pressure to work on both old and new code ○ Heavy reliance on automated tools to be effective ○ Deployment may affect production environment ○ Requires an expert dev team Sept 23 - Requirements Engineering Requirements: Requirements are statements that describe the users’/stakeholders’ needs and desires w/ respect to the software in question Each requirement: ○ Is short/concise piece of info ○ Says something about software system ○ Is agreed upon by stakeholders ○ Helps solve customers’ problems Functional Requirements ○ Defines function of system/its component ○ May involve calculations, technical details, data manipulation, and processing, and other specific functionality that define what system is supposed to accomplish ○ Expressed in form “system must do ____” Non-Functional Requirements ○ Requirement that specifies criteria that can be used to judge operation of system rather than behaviour ○ Define how system is supposed to be ○ Overall property of system as a whole or of particular aspect, no function ○ Expressed in form “system shall be _____” Requirements Engineering Requirements engineering is the process of developing a complete requirements specification for a project An action is communication activity that continues into modeling Action entails following tasks: ○ Inception Basic understanding of problem Define ppl who want solution Define nature of solution ○ Elicitation Elicit requirements and business forms from all stakeholders Goal is long-term aim that system must achieve Goals deal with both function and non-functional requirements Establish prioritization mechanism ○ Elaboration Focuses on developing refined requirements model that identifies aspects of software function, behaviour and info Creation of user scenarios Scenarios parsed to extract analysis classes and relationship between them ○ Negotiation Agree on scope of deliverable system that’s realistic for devs and customers Customer and stakeholder may ask for more than can be achieved or propose conflicting requirements Conflicts need to be reconciled via negotiation ○ Specification Documenting all requirements Can be: Written document, set of graphical models, formal math model, collection of user scenarios, or a prototype ○ Validation Review mechanism that looks for: Errors in content/interpretation, areas where clarification may be required, missing info, inconsistencies, conflicting/unrealistic requirements ○ Requirements management Set of traceability activities to help project team identify, control, and track requirements and their changes to requirements as the project proceeds Collaborative Requirements Gathering A collaborative approach to requirements gathering applies some variation of following guidelines ○ Meetings ○ Rules ○ Agenda ○ A facilitator ○ Definition mechanism Goal is to: ○ Identify the problem ○ Propose elements of solution ○ Negotiate different approaches ○ Specify preliminary set solution requirements As requirements are gathered, an overall vision of system functions and features begins to materialize A variety of work products can be created by requirements elicitation Characteristics of Good User Stories (INVEST) ○ Independent - Can be developed and delivered separately from other stories ○ Negotiable - Open to discussion and refinement ○ Valuable - Delivers value to end-user/the business ○ Estimable - Estimated for effort and time ○ Small - Small enough to be completed within single iteration ○ Testable - Clear criteria to verify the story is complete Epics Large bodies of work that can be broken into number of smaller tasks Can be seen as collection of related and interdependent user stories Completion of related use stories would lead to completion of epic In agile process, user stories are something team can commit to finish w/in single sprint while epics take longer to complete User Scenarios - Use Cases Use cases are collection of user scenario that describe thread of usage of system Use cases make it easier to understand how function and feature of system will be used Can take form of: narrative text, outline of tasks/interactions, template-based description, diagrammatic representation Each scenario is described from POV of ‘actor’ (person/device that interacts w/ software) Important that act and end use aren’t always the same Use cases vs user stories ○ Use Cases: Short or lengthy descriptions User flow/interaction In-depth guidance Detailed to write ○ User stories Short description Requirements who/why General guidance No technical detail Sept 24 - Recommended Process Model Principle for Organizing Software Projects It’s risky to use linear process model w/out ample feedback It’s never possible nor desirable to plan big up-front requirement gathering Up-front requirements gathering may not reduce costs/prevent time slippage Appropriate project management is integral to software development Docs should evolve w/ the software and not delay start of construction Involve stakeholders early and frequently in development process Testers need to become involved in process prior to software construction Recommended Process Model Textbook recommends hybrid of agile and spiral Characteristics of Agile vs Evolutionary Models Agile Spiral Not suitable for large, Not suitable for small, low-risk projects high-risk/mission critical projects Several steps required. Along with Minimal rules and minimal documentation done up front documentation Early involvement of testers Continuous involvement of testers Hard to accommodate product changes Easy to accommodate product until prototype is completed changes Continuous stakeholder involvement in Depends heavily on stakeholder planning and risk assessment interaction Requires formal project management and Easy to manage coordination Early delivery of partial solutions Project end not always obvious Informal risk management Product end always obvious Bui;t-in continuous process Good risk management involvement Process improvement handled at end of project Agile Spiral Model Requirements Definition ○ Encourage active stakeholder participation by matching their availability and valuing their input ○ Use simple models to reduce barriers to participation ○ Take time to explain requirements presentation techniques b4 using them ○ Adopt stakeholder terminology and avoid jargon ○ Use breadth-first approach to get the big picture of project done b4 getting bogged down in details ○ Developer and stakeholder refine requirements as user stories are ready to be implemented ○ Treat list of features like prioritized list and implement most important user stories first ○ Collaborate closely with stakeholders and document requirements so they are useful to all when creating the next prototype ○ Question the need to maintain models and documents not referred to in the future ○ Ensure management support for stakeholder and resource availability during requirements definition Elements of Agile Architectural Design ○ Focus on key quality attributes and incorporate them into prototypes as they are constructed ○ Keep in mind successful software products combine customer-visible features and the infrastructure needed to enable them ○ Agile architectures enable code maintainability and evolvability if attention is paid to architectural decisions and quality issues ○ Managing and synchronizing dependencies among functional and architectural requirements is needed to ensure evolving architecture will be ready for future increments Resource Estimation for Agile Spiral Model ○ Team should use historical data to develop an estimate of the number of days needed to complete each user story known at the start of project ○ Loosely organize user stories into sets that’ll make each sprint planned to complete a prototype ○ Sum the number of days to complete each sprint to provide estimate for duration of total project ○ Revise estimate as requirements are added to project or prototypes are delivered as requirements are added to project and accepted by stakeholders First Prototype Guidelines ○ Transition from paper prototype to software design ○ Prototype user interface ○ Create a virtual prototype ○ Add input and output to prototype ○ Test prototype ○ Prototype with deployment in mind Prototype Evaluation ○ Provide scaffolding when asking for prototype feedback ○ Test prototype on right people ○ Ask right questions ○ Be neutral when presenting alternative to users ○ Adapt while testing ○ Allow the user to contribute ideas Go No Go Decision ○ Revised cost estimates and schedule changes are proposed based on changes that were requested when evaluating the current prototype ○ Risk of exceeding budget and missing project delivery date is assessed ○ Risk or failing to satisfy user expectations discussed with stakeholders and sometime senior management ○ Goal of risk assessment is to get commitment from stakeholders and management to provide resources needed to create next prototype Evolution of Prototypes ○ First step is to collect all feedback and data from the evaluation of the current prototype. The developers and stakeholders then begin negotiations to plan the creation of another prototype ○ Once the desired features for the new prototype have been agreed upon, consideration is given to any known time and budget constraints as well as the technical feasibility of implementing the prototype. If development risks are deemed to be acceptable, work continues ○ Each prototype should be designed to allow for future changes to avoid throwing it away and creating next prototype from scratch Release Candidates ○ Protype considered as release candidate is subjected to user acceptance testing in addition to testing conducted during prototype construction ○ User acceptance tests are based on acceptance criteria that were recorded as each user story was created and added to the product backlog ○ User feedback during acceptance testing should be organized by user-visible functions as portrayed via user interface ○ Developers should make changes only if these changes won’t delay release of prototype ○ If changes are made, they need to be verified in a second round of acceptance testing before moving on ○ Issues and lessons learned from creating the release candidate should be documented and considered by the developers and stakeholders as part of project post mortem ○ Lessons learned from the current product can help developers make better cost and time estimates for similar projects in the future Software Release Maintenance ○ Maintenance - Activities needed to keep software operational after it has been accepted and released in the end-user environment ○ Corrective Maintenance - Reactive modification of software to repair problem discovered after software has been delivered ○ Adaptive Maintenance - Reactive modification of software after delivery to keep software usable in changing environment ○ Perfective Maintenance - Proactive modification of software after delivery to provide new user features, better program code structure, or improved documentation ○ Preventive Maintenance - Proactive modification software after delivery to correct product faults b4 discovery by users Sept 30 - Requirements Modeling Domain Analysis Domain - The targeted subject area of a computer program Software Domain Analysis - The identification, analysis, and specification of common requirements from specific application domain Object-oriented Domain Analysis - Identification, analysis, and specification of common, reusable capabilities w/in specific app domain, in terms of common objects, classes, subassemblies and frameworks Benefits ○ Accelerates development ○ Improves communication between stakeholders ○ Leads to higher quality system, better meeting the needs of stakeholders ○ Helps in anticipating extensions and changes that could be forthcoming Domain expert - Someone who has deep knowledge of the domain and can provide valuable info to an analysis Domain Analysis Process ○ Identify and define domain to be investigated ○ Collect representative sample of apps in domain ○ Analyze each app in sample ○ Develop domain analysis model using this info Requirements Modelling Requirements Analysis ○ Specidies software’s operational characteristics ○ Indicate software’s interface with other system elements ○ Establishes constraints that software must meet Requirements Model - Bridges gap between system-level description and software design Scenario-Based model ○ Depicts requirements from pov of various system actors Class-oriented model ○ Represent object-oriented classes and how classes collab to achieve system requirements Behavioural model ○ Depict how software reacts to internal/external ‘events’ Data model ○ Depict info domain for problem Flow-oriented model ○ Represent functional elements of system and how they transform data in system Rule of Thumb ○ Level of abstraction should be high ○ Analysis model should provide insight into info domain, function, and behaviour of software ○ Delay consideration of infrastructure and non-functional models until later in modeling activity ○ Analysis model provides value to all stakeholders, keep model simple as possible Class-Based Modeling Represents: ○ Objects that system will manipulate ○ Operations that will applied to objects to affect manipulation ○ Relationships(ex. hierarchical) between objects ○ Collaboration that occur between classes that are defined Identifying analysis classes ○ Examining usage scenarios developed as part of requirement models and perform ‘grammatical parse’ Classes are determined by underlining each noun Synonyms should be noted If class(noun) is required to implement solution, then is part of solution space, otherwise it’s part of problem space Potential Analysis Classes ○ External Entities - produce/consume info ○ Things - Part of info domain for problem ○ Occurrences - Events that occur w/in context of system ops ○ Roles - Played by ppl who interact w/ system ○ Organizational Units - Relevant to application ○ Places - Establish context of problem and overall function ○ Structures - Define class objects/related classes of objects Analysis Class Selection - Characteristics used as you consider each class ○ Retained information ○ Needed services ○ Multiple attributes ○ Common attributes ○ Common operations ○ Essential requirements Defining Attributes ○ Describe class that has been selected for inclusion in analysis model ○ Attributes that define class - what is meant by class in context of problem space ○ Develop meaningful set of attributes for analysis class, should study each use case and select those things that reasonably belong to class Define Operation ○ Operations define behaviour of object ○ Can be divided into 4 categories Operation that manip data Operations that perform computation Operations that inquire about state Operations that monitor object for occurrence of controlling event ○ Functions are accomplished by operating on attributes and/or associations CRC Modeling Class-Responsibility-Collaborator (CRC) - Provides simple means for identifying and organizing classes relevant to system requirements CRC model is collection of standard index cards that represent classes Cards of divided into 3 sections ○ Top - Name of class ○ Left - Class responsibilities list ○ Right - Collaborators list Responsibilities ○ Attributes/operations that are relevant to class ○ Collaborators are those classes that provide class with needed info/action required to complete responsibility CRC Model Review Process ○ All stakeholders in CRC are given subset of index cards ○ Review leader reads the use case. When they come to named object, pass a token to person holding corresponding index card ○ When token is passed, holder of class card is asked to describe responsibilities, group determines whether responsibilities satisfies use case requirement ○ If error is found, modification are made to card Behavioural Modeling Indicates how software will respond to internal/external events UML activity diagram can be used to model how system elements respond to internal events UML state diagrams can be used to model how system elements respond to external events Creating Behavioural Models ○ Evaluate all use cases to fully understand sequence of interaction ○ Identify events that drive interaction sequence and understand how events relate to specific objects ○ Create sequence diagram and/or activity diagrams for each use case ○ Build state diagram for objects in the system ○ Review behavioural model for accuracy and consistency Identifying Event ○ Use case represents a sequence of activities that involve actors and the system ○ An event occurs whenever system and an actor exchange info ○ Event is not the info that has been exchanged, but rather fact that info has been exchanged ○ Use case needs to be examined for points of information exchange ○ Events are used to trigger state transitions State Representations State of system is a set of observable circumstances that characterizes the behaviour of the system at a given time In context of behavioural modeling, 2 different characterizations of states must be considered ○ State of each class as the system performs its function ○ State of system as observed from the outside as the system performs its function Event must occur to force an object to make a state transition Actions might occur as consequence of making a transition Several representations can be used: ○ State Diagram - Indicates how an individual class changes state based on external events ○ Sequence Diagram - Shows behaviour of software as function of time State Diagrams Represent active states for each class and the events that cause changes between these active states ○ States - Represented by boxes, given a name and condition ○ Transitions - Represented by arrows with label ○ Guards - Transition with conditions (ex. Password = correct) ○ Actions - Optional, happens concurrently w/ or as consequence of transition When to Use ○ Used for describing behaviour of an object across one or more use cases ○ Not good at describing behaviour that involve several different objects collaborating ○ Good for showing change of state in an object based on external events ○ Don’t draw for every class in system Sequence Diagrams UML sequence diagram can be used for behavioural modeling Can also be used to show how event cause transition from object to object Once events have been identified for use case, modeler creates sequence diagrams Sequence diagram is shorthand version of use case ○ Objects/Actors - Labelled with name ○ Lifeline - Represents time in diagram and lifetime of object ○ Activation Bar - Represent time spent to process activity ○ Messages - Represented by arrows labeled with description of message sent between objects. Type of arrow signals synchronous/asynchronous Dotted line = returned information, synchronous arrows have return info implied Found messages - Represents message coming from outside diagram, has a circle at one end ○ Interaction Frames - Allows to define control (ex, loops) When to Use ○ Used for describing behaviour of several objects w/in single use case ○ Good for showing collaborations among objects ○ Not good at showing precise definition of behaviour Use state diagrams for behaviour of single object and activity for concurrency/more complex behaviour, CRC for quick exploration of alternative interaction Oct 7 - Design Concepts and Modeling Software Design Good software design should exhibit ○ Firmness: Program shouldn’t have any bugs that inhibit its function ○ Commodity: Program should be suitable for the purposes for which it was intended ○ Delight: Experience of using program should be pleasurable one Software Design encompasses set of principles, concepts and practices that lead to development of high-quality system ○ Design Principles: Overriding philosophy that guides the designer ○ Design Concepts: Concepts that must be understood before design practices are applied ○ Design Practices: PRactices that lead to the creation of various representations of the software Why Care About Design? ○ Technical Debt: Costs associated with rework caused by choosing “quick and dirty” solution rather than better approach that takes more time ○ Pay down technical debt Refactoring Software Engineering Design Data/Class Design ○ Transforms analysis classes into implementation classes and data structures (design classes) ○ UML Class Diagrams and Entity-relationship diagrams(ERD) often used Architectural Design ○ Defines relationships among the major software structural elements ○ Decomposes the system into interacting components ○ Defines the structure and properties of the components ○ Defines the structure and properties of the components and the relationship among these components Interface Design ○ Defines how software elements, hardware elements, and end-users communicate ○ Focuses on user interfaces(UI), user experience (UX), internal interfaces, and external interfaces Component-Level Design ○ Transforms structural elements into procedural descriptions of software components ○ Internal data structures and processing details of all the software components Analysis Models ○ Scenario-Based Elements - Used at interface design Use cases, use case diagrams, user stories ○ Behavioural Elements - Used at interface and component design Activity, swimlane, state, and sequence diagrams ○ Class-Based Elements - Used at data/class, architectural, and component design Class diagrams, crc modeling These models and designs become blueprint for the construction activity Good design leads to a high-quality software product Design and Quality Three recommends characteristics that serve as a guide for the evaluation of a good design: ○ The design must implement all explicit requirements and must accommodate all implicit requirements desired by customer ○ The design must be readable, understandable guide for those who generate code and for those who test nad support the software ○ The design should provide a complete picture of the software addressing the date, functional, and behavioural domains from the implementation perspective Quality Guidelines ○ These characteristics are not achieved by change; they are achieved through application of fundamental design principles, systematic methodology, and through review ○ On method of ensure quality is conducting Technical Reviews(TR) TR - Meeting conducted by members of software team 204 ppl, one review leader(facilitates meeting), one recorder(takes notes), one producer(person whose work product is being reviewed) Review work product and note all errors, omissions, or ambiguity Decided if further work is needed by producer b4 design work can be approved Design Concepts Abstraction ○ Conceptual process wherein general rules and concept are derived from the usage and classification of specific examples, literal signifiers, first principles, or other methods ○ Procedural Abstraction - Sequence of instructions that have specific and limited function Word use for camera in SafeHome system Use implies long sequence of procedural steps ○ Data Abstraction - Collection of data that describes a data object Abstraction for camera would encompass a set of attributes that describe a camera Separation of Concerns ○ Separation of concerns suggests that a complex problem can be more easily handled if it is subdivided into pieces that can each be solved independently ○ A concern is a feature or behaviour that is part of requirements model ○ By separating concerns into smaller pieces, a problem takes less effort and time to solve using a divide-and-conquer strategy Modularity ○ Modularity is the most common manifestation of separation of concerns ○ Software is divided into separately named components(modules) that are integrated to satisfy requirements ○ In almost all instances, you should break the design into many modules, hoping to make understanding the design easier and reduce the cost required to build the software Information Hiding ○ The intent of information hiding is to hide the details of data structures and procedural processing behind a module interface ○ Information hiding implies that effective modularity can be achieved by defining a set of independent modules that communicate with one another only when necessary ○ Benefits Reducing the likelihood of ‘side effects’ Limiting the global impact of local design decisions Emphasizing communication through controlled interfaces Discouraging use of global data Encapsulation 0 an attribute of high-quality design Functional Independence ○ IS achieved by developing modules with ‘single minded’ purpose and an ‘aversion’ to excessive interaction with other modules ○ Assessed on 2 characteristics: ○ Cohesion - indication of relative functional strength of module A cohesive module performs a single task, requiring little interaction with other components in other parts of a program Stated simple, a cohesive module should do just one thing ○ Coupling - indication of relative interdependence among modules Depends on interface complexity between modules Aim for lowest possible coupling Simple connectivity results in software that is easier to understand and less likely to propagate errors Stepwise Refinement ○ Is a top-down design strategy An app is developed by successively refining levels of procedural detail A hierarchy is developed by decomposing a macroscopic statement of a function in stepwise fashion until programming language statements are reached ○ Refinement is process of elaboration, successively adding more and more detail as it is applied ○ Abstraction and refinement are complementary concepts Abstraction enables you to specify data dn procedure internally but suppress the need for outsiders to have knowledge of low-level details Refinement helps you to reveal low-level details as design progresses ○ Both abstraction and refinement allow you to create a complete design model as the design developed over time Refactoring ○ A reorganization technique that simplifies the design(or code) of component w/o changing its function/behaviour ○ Refactoring can be important design activity for many agile methods to ensure sound design despite frequent additions, modifications, and evolutions Design Classes ○ Each of these analysis classes describe some element of the problem domain, focusing on aspects of the problem that are user visible ○ As design model evolved, you will define set of design classes that refine these analysis classes by providing additional detail that will enable the classes to be implemented ○ 4 characteristics of well-defined design class Complete and sufficient - Class is complete if it includes all necessary attributes and methods. It’s sufficient if it contains only those methods needed to achieve class intent Primitiveness - Each class method focuses on providing one service for class High cohesion - Small, focused, single-minded classes with attributes and methods oriented around that single focus Low coupling - Class collaboration kept to minimum, with classes only having limited knowledge of other classes Design Model The design model use many of the same diagrams that were used in the requirements/analysis model In some cases, there’s clear distinction between models, and in others, requirements/analysis model slowly blends into the design and a clear distinction is less obvious Design mode is typically more refined and detailed, with more attention given to the implementation that is to come Elements of Design Model Data design create model of data and/or info that’s represented at a high level of abstraction ○ Then data model is refined into progressively more implementation-specific representations that can be processed effectively and efficiently ○ Architecture and design of data will have profound influence on architecture of software that must process it Data model is comprised of data objects and database architectures ○ Data object can be external entity, thing, event, place, organizational unit, or structure ○ Data objects contain a set of attributes that act as quality characteristic/descriptor of object ○ Data object may be connected to one another in many different ways Interface Design Elements Interface design elements for software depict information flows into and out of system and how it’s communicated among the components that are part of the architecture There are 3 important elements ○ User interface ○ External interfaces to other systems, divides, networks, or other producers/consumers of info ○ Internal interfaces between various design components Deployment-Level Design Elements Indicated how software functionality and subsystems will be allocated within the physical computing environment Modeled using UML deployment diagrams ○ Descriptor form deployment diagrams show computing environment but don’t indicate config details ○ Instance form deployment diagrams identifying specific named hardware config, are developed during later stages of design Oct 7 - Architectural Design What is Software Architecture Architecture of a software system is a comprehensive framework that describes its form and structure - its components and how they fit together Representation that allows developers to: ○ Analyze the effectiveness of the design ○ Consider architectural alternative ○ Reduce risk Software Component ○ Parts of a system that break the complexity into manageable parts ○ Hides(encapsulates) implementation details behind an interface ○ Components can be swapped in and out so long as they share a common interface ○ Software Component Views Object-Oriented View - A set of one or more collaborating classes Traditional View - Functional element of a program (aka module) Process-Related View - Pre-existing prepackaged component or design pattern Why is Architecture Important ○ Provide representations that facilitate communication with stakeholders ○ Highlight early design decisions with profound impact on all software engineering work that follows ○ Gives an ‘intellectually graspable’ model of the system and how its components work together Architectural Styles Each style describes a system category that encompasses ○ Set of Components - that perform a function required by a system ○ Set of Connectors - that enable “communication, coordination, and cooperation” among components ○ Constraint - that define how components can be integrated to form the system ○ Semantic Models - that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts Data-centered ○ A data store resides at the center of the architecture, accessed frequently by other components that update, add, delete, or otherwise modify data in the store Data-Flow ○ Input data is transformed through a series of computational components into output data ○ Pipe-and-filter pattern uses filters (computational components) connected by pipes that transmits the data between components ○ Filters don’t require knowledge of each other Call-and-return ○ 2 substyles Main program/subprogram - A main program invokes a number of program components, which in turn may invoke still other components Remote Procedure Call - Components are distributed across multiple networked computers Object-Oriented ○ The components of a system encapsulate data and the operations that must be applied to manipulate the data ○ Communication and coordination between components are accomplished via message passing(method invocation) Layered ○ Layers are defined, each providing services to layers above through operations completed w/in the layer or by leveraging services from lower layers ○ Outer layers interface more directly with the user, innermost layers interface w/ the os and/or underlying hardware ○ Intermediate layers provide utility services and other application functions Model-View-Controller(MVC) ○ Often used in web and mobile dev ○ Comprised of 3 kinds of components Model - Contains all app-specific content and processing logic View - Contains all the interface-specific functions and handles presentation of content to the end user Controller - Manages access to the model and view, coordinates flow of data ○ Many other styles exist and you can also combine multiple styles together Architectural Patterns Architectural patterns address an app=specific problem w/in a specific context and under a set of limitations and constraints The pattern proposes an architectural solution that can serve as the basis for the architectural design Patterns can be used in conjunction with an architectural style to shape the overall structure of a system The style typically influences the architecture in its entirety, while patterns tend to focus on one aspect of the architecture at the time Architectural Considerations Several considerations when choosing an architecture: ○ Economy - Software is uncluttered and relies on abstraction to reduce unnecessary detail ○ Visibility - Architectural decisions and their justifications should be obvious to software engineers who review ○ Spacing - Separation of concerns in a design w/o introducing hidden dependencies ○ Symmetry - Architectural symmetry implies that a system is consistent and balanced in its attributes ○ Emergence - Emergen, self-organized behaviour and control are key to creating scalable, efficient, and economic software architectures Architectural Design As architectural design begins, software must be placed into context ○ The design should define the external entities(other systems, devices, ppl) that the software interacts with and the nature of their interactions A set of architectural archetypes should be identified ○ An archetype is an abstraction that represents one element of system behaviour The designer specifies the structure of the system be defining and refining software components that implement each archetype Architectural Context UML doesn’t contain specific diagrams for system context ○ Can use combo of use cases, class, component, activity, sequence, and collaboration diagrams Or can make use of architectural context design(ACD) Defining Archetypes An archetype is a class or pattern that represents a core abstraction that is critical to the design of an architecture for the target system Generally, a relatively small set of archetypes is required to design even relatively complex systems The system architecture is composed of archetypes, which represent stable elements of the architecture. These may be instantiated in different ways based on behaviour of the system In many cases, archetypes can be derived by examining the analysis classes defined as part of the requirements model Archetype Diagram Node - A node represents a cohesive collection of input and output elements; for example, a node might be composed of ○ Various sensors ○ A variety of alarm(output) indicators Detector - An abstraction that encompasses all sensing equipment feeding information into the target system Indicator - An abstraction that represents all mechanisms for indicating an alarm is occurring Controller - An abstraction that depicts the mechanism that allows the arming or disarming of a node;if controllers reside on network, they have ability to communicate with one another Refining into Components As the software architecture is refined into components, the structure of the system begins to emerge How are these components chosen? ○ Begin with the classes that were described as part of the requirements model ○ These classes represent entities w/in the application domain that must be addressed w/in the software architecture ○ From there, identify infrastructure components that enable app components but are not part of the app domain Architectural Reviews Assess the ability of the software architecture to meet the systems quality requirements and identify potential risks Have potential to reduce project cost by detecting design problems early Unlike requirements review, architecture reviews typically invoke only dev and independent experts Often make use of experience-based reviews, prototype evaluation, scenario reviews, and checklists Oct 21 - Wireframes What are Wireframes? Simple sketch of user interface Can be used to show stakeholders to get feedback on UI design Simple nature make them more “critiqueable” and forces stakeholders and users to focus on important details 3 main types ○ Low Fidelity - Create new concepts, focus on ideas not detail, generate lots of options ○ Mid Fidelity - Used to get feedback, great for creating prototypes ○ High Fidelity - Provide detailed instructions, use as guide for development User Experience Design UX vs UI ○ UX is more interactive and what scenarios are going to happen ○ UI is more of the visual design and layout Strategy ○ Identifies user needs and customer business goals that form the basis for all UX design work ○ Subcomponents: User needs Business goals Scope ○ Includes both the functional and content requirements needed to realize a feature set consistent with the project strategy ○ Subcomponents: Functional specifications Content requirements Structure ○ Consists of the interaction design and information architecture ○ Subcomponents: Interaction design Information architecture Skeleton ○ Comprised of three components: information design, interface design, navigation design ○ Subcomponents: Interface design Navigation design Information design Surface ○ Presents visual design or the appearance of the finished project to its users ○ Subcomponents: Visual Design- An artistic endeavor that complements the technical aspects of the user experience design The Golden Rules 1. Place the user in control ○ Define interaction modes in a way that doesn’t force user into unnecessary or desired actions ○ Provide for flexible interaction ○ Allow user interaction to be interruptible and undoable ○ Streamline interaction to be customized ○ Hide technical internals from the casual user ○ Design for direct interaction with screen objects 2. Reduce the user’s memory load ○ Reduce demand on short-term memory ○ Establish meaningful defaults ○ Define shortcuts that are intuitive ○ The visual layout of the interface should be based on real-world metaphor ○ Disclose info in a progressive fashion 3. Make the interface consistent ○ Allow the user to put the current task into a meaningful context ○ Maintain consistency across a family of applications ○ If past interactive models have created user expectations, don’t make changes unless there is compelling reason to do so User Research Need to get better understanding of the users of the system 2 main representations for modeling and understanding users ○ Customer Journey Map ○ User Personas Customer Journey Map 1. Gather stakeholders 2. Conduct research - Collect all info you can about things users may experience using the software and define customer phases 3. Build the model - Make the deliverable visually appealing and ensure touchpoints are identifies 4. Identity gaps - Note any gaps in the customer experience or points of friction or pain 5. Implement your findings - Assign responsible parties to bridge the gaps and resolve pain points found User Personas ○ Fictional representation of your ideal end user ○ Based on user research and incorporates the needs, goals, and observed behaviour pattern of your user base ○ Used to improve product designers’ abilities to see through the eyes of target users 1. Data Collection and Analysis - Stakeholders collect info about end users and determine each user group’s needs 2. Describe Personas - Developers decide how many personas to create and decide which persona will be their focus 3. Develop Scenarios - Scenarios are user stories about how personas will use the software. They may focus on the touchpoints and obstacles described in the customer journey 4. Acceptance by Stakeholders - Scenarios are validated using review technique or demonstration called cognitive walkthrough User Interface Design Using info developed during interface analysis, define interface objects and actions Define tasks and events that will cause the state of the user interface to change and model this behaviour Depict each interface state as it will actually look to the end-user Evaluate the interface design with prototype reviews and user testing User Interface Design Evaluation Criteria The UI design model should be evaluated in early design reviews ○ Length and complexity - Provide an indication of amount of learning required by users of the system Number of user tasks and average number of actions per task ○ Provide indication of interaction time and the overall efficiency of the system Number of actions, tasks, and system states ○ Imply the memory load on users of the system Interface style, help facilities, and error-handling protocol ○ Indication of the complexity of the interface and the degree to which it will be accepted by the user Oct 22 - Component-Level Design What is a component (Software Component): “A modular, deployable, and replaceable part of the system that encapsulates implementation and exposes a set of interfaces” Parts of a system that break the complexity into manageable parts Hides implementation details behind an interface Component Elaboration Begin with the classes from the analysis model, divided into components and define interfaces Analysis classes become design components Interfaces identified based on operations in analysis classes Must now refine and elaborate on each analysis class to create out design classes Detail is added for each attribute, operation, and interface Data structures for each attribute are specified Algorithmic detail for each operation is designed The mechanisms required to implement the interface are designed Infrastructure classes to support the design classes may need to be created Once complete, all detail necessary for implementation has been generated and is available to devs Basic Design Principles Open-Closed Principle ○ A module component should be open for extension but closed for modification ○ Specify the component in a way that allows it to be extended without the need to make internal modifications to the component Liskov Substitution Principle ○ Subclasses should be substitutable for their base classes ○ A component that uses a base class should continue to function properly if a class derived from the base class is passed to the component instead Dependency Inversion Principle ○ Depend on abstractions, not on concretions ○ Abstractions are the place where a design can be extended without great complication ○ The more components depend on concrete components. The more difficult it will be to extend Interface Segregation Principle ○ Many client-specific interfaces are better than one general purpose interface ○ Only those operations that are relevant to an individual client category should be specified in the interface for that client ○ No code should be forced to depend on operations it doesn’t use Release Reuse Equivalency Principle ○ Effective reuse requires tracking of releases from a change control system. The package is the effective unit of reuse and release ○ When designing for reuse, don’t address classes individually, group them into packages that can be more easily managed Common Closure Principle ○ Classes that change together belong together ○ Classes should be packaged cohesively ○ Classes in the same package should address the same functional or behavioural area ○ When characteristics of that area change, it is likely that only those classes within the package will require modification Common Reuse Principle ○ Classes that aren’t reused together shouldn’t be grouped together ○ Only classes that are reused together should be included within the same package ○ Unrelated classes lead to extra integration work and testing ○ Also means new releases of the package even if changes have no impact on some systems Cohesion Traditional View - the “single-mindedness” of a module Object-Oriented View - cohesion implies that a component encapsulates only attributes and operations that are closely related to one another and the component itself Types of Cohesion ○ Functional - Module performs one and only one computation ○ Layer - Occurs when a higher layer accesses the services of a lower layer, but lower layers don’t access higher layers ○ Communicational - All operations that access the same data are defined within one class Coupling Traditional View - Degree to which a component is connected to other components and to the external world Object-Oriented View - Qualitative measure of the degree to which classes are connected to one another Types of Coupling ○ Content - Occurs when one component “surreptitiously” modifies data that is internal to another component ○ Control - Occurs when control flags are passed to components to request alternate behaviours when invoked ○ External - Occurs when a component communicates or collaborates with infrastructure components Want high cohesion and low coupling Component-Level Design 1. Identify all design classes that correspond to the problem domain 2. Identify all design classes that correspond to the infrastructure domain 3. Elaborate all design classes that aren’t acquired as reusable components a. Specify message details when classes or components collaborate. Collaboration diagrams commonly uses b. Identify appropriate interfaces for each component c. Elaborate attributes, define data types, and data structures d. Describe processing flow within each operation in detail, using pseudocode, an activity diagram, or a flowchart 4. Describe persistent data sources and identify the classes required to manage them 5. Develop and elaborate behavioural representations for a class or component; state diagrams can be useful for this 6. Elaborate deployment diagrams to provide additional implementation detail 7. Refactor every component-level design representation and always consider alternative Oct 28 - Version Control Version Control A system that record changes to a file/set of files over time so that you can restore specific versions later Version control can: ○ Revert select files to previous state ○ Keep a history of changes, who made them and why ○ Compare different versions of same file ○ Act as a distributed backup of the project ○ Allow for experimentation that can easily be reverted ○ Allow multiple developers to work on the same code base simultaneously ○ Help resolve conflict between different devs work Centralized Version Control Systems ○ Single server that contains all the versioned files and history ○ Clients check out snapshot of files from central server ○ Single point of failure, can only checkout/commit files and view version history while you have a connection to the server Distributed Version Control Systems ○ Full mirror(clone) of the repository is stored on each computer ○ If central server is lost, it can be restored from any clone ○ Allows offline access ○ Can be faster(less network access) Git Distributed version control system - created in 2005 by Linus Torvalds Git stores version as a stream of file snapshots Git has 3 main states that your files can reside in ○ Modified means that you have changed the file but haven’t committed it to your database ○ Staged means that you have marked a modified file in its current version to go into you next committed snapshot ○ Committed means that the data is safely stored in your local database Git Branches In many cases, you may want to experiment/work on a new feature w/o impacting your existing code base The experimentation or feature development may require multiple complex changes, so simply keeping it in the working tree until it’s ready to commit/stage is not possible The solution if branches In Git, branches are effectively a pointed to snapshot of your changes When working on a new feature, fixing a bug, or experimenting it’s a good idea to create a new branch Branches may diverge from default branch Can switch between branches as needed Oct 31 - Design Patterns: Patterns in Design Design patterns offer codified method for describing problem and their solutions, allowing us to build a repo of patterns that enable easy evaluation and reuse Design pattern can be thought as 3-part rule which expresses a relation between a certain context, a problem, and solution Context allows reader to understand the environment in which the problem resides and what solution might be appropriate w/in that environment Effective Design Pattern Solves a problem Proven concept Solution isn’t obvious Describes a relationship Elegant in its approach and utility Kinds of Patterns Architectural patterns ○ Describe broad-based design problems are solved using a structural approach Data patterns ○ Describe recurring data-oriented problems and the data modeling solutions that can be used to solve them Component patterns ○ Address problems associated with the development of subsystems and components, the manner in which they communicate with one another, and their placement w/in larger architecture Interface Design patterns ○ Describe common user interface problems and their solution with a system of forces that includes the specific characteristics of end-users Web Application patterns ○ Address problems that are encountered when building web-based applications and often incorporate patterns from other categories Mobile patterns ○ Describes solutions to problems commonly encountered when developing for mobile platforms Object-oriented patterns ○ Patterns that are particularly relevant to object-oriented design ○ Typically fall into 3 subcategories Creational patterns Structural patterns Behavioural patterns Object-Oriented Patterns Creational patterns ○ Focus on ‘creation, composition, and representation of objects’ ○ Ex. Abstract factory pattern - centralize decision of what factory to instantiate Builder pattern - separates the construction of a complex object from its representation Structural patterns ○ Focus on problems and solutions associated with how classes and objects are organized and integrated to build a larger structure ○ Ex. Adapter pattern - ‘Adapts’ on interface for a class into one that a client expects Container pattern - Crate objects for the sole purpose of holding other objects and managing them Behavioural patterns ○ Address problems associated with the assignment of responsibility between objects and the manner in which communication is affected between objects ○ Ex. Chain of responsibility pattern - Command objects are handled or passed on to other objects by logic-containing processing objects Command pattern - Command objects encapsulate an action and its parameters Where to find patterns Created by an individual or organization for future projects as they develop software From pre-existing book/catalogs of software patterns From online repos or machine learning pattern discovery Pattern Description Pattern descriptors and template vary Recommended is one from textbook Anti-Patterns Describe commonly used solutions to design problems that usually have negative effects on software quality ○ Provide tools to help devs recognize when these problems exist and complement better solutions to these problems ○ Provide guidance to devs looking for ways to refactor software to improve its quality ○ Can be used by technical reviewers to uncover areas of concerns Examples ○ Blob - Single class with large number of attributes, operators, or both ○ Stovepipe System - Barely maintainable assemblage of ill-related components ○ Boat Anchor - Retaining part of system that no longer has any use ○ Spaghetti Code - Program whose structure is barely comprehensible, especially because of misuse of code structures ○ Copy and Paste Programming - Copying existing code several times rather than creating generic solution ○ Silver Bullet - Assume that a favourite technical solution will always solve a larger process or problem ○ Programming by Permutation - Trying to approach a solution by successively modifying the code to see if it works Pattern-Based Design A software designer begins with requirements model The requirements model describes the problem set, establishes the context, and identifies the system of forces that hold sway Based on the requirements model; consider design concepts and consider design quality attributes. This helps identify the exact problem set, context, and forces at play Based on these and the problem you are faced with, evaluate if a preexisting pattern addresses your needs If the pattern seems appropriate, incorporate the pattern into your design If no pattern fits your needs/new problem, use the methods and modeling tools available for architectural component-level, and interface design to create a new solution Finally, evaluate the design and determine if the exact problem set, context, and forces are correct and are appropriate for the patterns you’re using Throughout design process, the designer should look for opportunities to apply existing design patterns rather than synthesizing a new design when doing so is unnecessary Common Design Mistakes With Patterns Not enough time has been spent to understand the underlying problem and you select a pattern that look right, but is inappropriate for the solution required Once the wrong pattern is selected, you refuse to see your error and force fit the pattern The problem has forces that aren’t considered by the pattern you’ve chosen, resulting in poor fit Sometimes a pattern is applied too literally and required adaptations for your problem aren’t implemented Nov 4 - Quality Concepts Software Quality 3 kinds of quality may be encountered ○ Quality of Design - Encompasses requirements, specifications, and the design of the system ○ Quality of Conformance - An issue focused primarily on implementation ○ Use Satisfaction - Compliant product + good quality + delivery w/in budget and schedule Software quality can be defined as: An effective process applied in a manner that creates a useful product that provides measurable value for those who produce it and those who use it ○ Effective Software Process Establishes the infrastructure that supports any effect at building high quality software product Encompasses both the framework and umbrella activities ○ Useful Product Delivers the content, functions, and features that the end user desires in a reliable and error-free way Satisfies requirements that have been explicitly/implicitly stated by stakeholders ○ Measurable Value Provides benefits for both the software organization and the end-user community The software organization gains added value because high quality software requires less maintenance effort and reduced customer support The user community gains added value because the application provides a useful capability in a way that expedites some business process Quality Factors Quality Factors - High-level quality attributes of software which can be accessed directly either qualitatively/quantitatively McCall’s Software Quality Factors ○ Product Operation Correctness, reliability, usability, integrity, and efficiency ○ Product Transition Portability, reusability, and interoperability ○ Product Revision Maintainability, flexibility, and testability ○ Many other quality models and standards have been proposed in software eng lit. Qualitative and Quantitative Quality Assessment Quality factors can be assessed qualitatively/quantitatively Quality attributes can sometimes be described quantitatively using software metrics If software matric values computed for code fragment fall outside range of acceptable values, it may signal existence of quality problem Metrics represent indirect measures; we never really measure quality but rather manifestation of quality Software Quality Dilemma If you produce a software system that has terrible quality, you lose because no one will want to buy it If you spend infinite time, extremely large effort, and huge sums of money to build perfect piece of software, it’s gonna to long to complete and will be so expensive to produce that you;ll be out of business as you either missed market window, or you exhausted all your resources Need to find middle ground where product is good enough not to be rejected right away but also not take too long or cost too much complete “Good Enough” Software One suggested solution to the software quality dilemma is “good enough” software What is “good enough” software ○ Delivers high quality functions and features that end-users desire, but at the sametime it delivers other more obscure/specialised function and feature that contain known bugs ○ The hope is that vast majority of end users wither will miss the bugs/overlook them as they are otherwise very satisfied with what the software delivers Issues ○ “Good enough” may work in some app domains and for a few major software companies ○ If you work for small company and deliver “good enough” product, risk permanent damage to company reputation and may lose customers ○ May never get change to deliver 2.0 because of bad buzz may cause sales to plummet and fold company ○ If you work in certain app domains delivering “good enough” may considered negligent and open company to expensive litigation Cost of Quality Delivery quality software has a cost, in terms of time and money Lack of quality also has a cost, not only end users who must live with buggy software, but also to software organization that has built and must maintain it ○ Reputation damages may cost more than spending extra time creating a finished product ○ Negligence and false advertising can also lead to potential legal liability Quality costs fall into one of the following categories ○ Prevention costs - quality planning, formal technical reviews, test equipment, training. Includes: Cost of management activities required to plan and coordinate quality control and quality assurance Cost of added technical activities to develop complete requirements and design models Test planning costs The cost of all training associated with these activities ○ Appraisal Costs - Conducting technical reviews, data collection and metrics evaluation, testing and debugging. Appraisal include activities that gain insight into various aspects of a software product’s condition: Cost of conducting technical reviews for software engineering work products Cost of data collection and metric evaluation Cost of testing and debugging ○ Internal Failure Costs - Rework, repair, failure mode analysis. Internal failure costs are incurred when you detect an error in a product prior to shipment; such costs include Cost required to perform rework to correct error Cost that occurs when rework inadvertently generates side effects that must be mitigated Costs associated with the collection of quality metric that allow an organization to assess the modes of failure ○ External Failure Costs - Complaint resolution, product return and replacement, help line support, warranty work. External failure costs are associated with defects found after the product has been shipped to the customer; ex includes: Complaint resolution Product return and replacement Help line support Labor costs associated with warranty work The costs to find and repair an error/defect increase dramatically as we go from prevention to appraisal to internal failure to external failure costs Quality and Risk Low quality software leads to risk for both the dev and the end user Easy to see potential risk in app domains such as: self driving cars, health and medicine, aerospace, etc. Significant risk also exists in more traditional domains in term of liability Achieving Software Quality Software quality doesn't just appear Software quality is the result of good project management and solid engineering practice This come into play in 4 categories ○ Software engineering methods ○ Project management techniques ○ Quality control ○ Quality assurance Nov 11 - Software Testing Verification and Validation Software testing is one element of verification and validation Verification - Refers to the set of tasks that ensure that software correctly implements a specific function Validation - Refers to a different set of tasks that ensure that the software that has been built is traceable to customer requirements Who does Testing ○ Software devs - responsible for individual program components ○ Independent test group(ITG) Involved after software architecture is complete Role of itg is to remove conflict of interest associated with letting the builder test the thing that has been built Types of Testing Unit Testing - Individual units of source code are tested to determine whether they are fit to use Integration testing - Individual software modules are combined and tested as a group Validation testing - Validates the requirements established as part of requirements modeling against the software that has been constructed System Testing - Software and other system elements are tested as a whole all together Software Testing Strategy Testing begins at the component level and works “outware” toward the integration of entire system Integration testing is done when components are combined and tested After software is integrated, high-order tests such as validation and system testing are conducted Can’t wait until system is fully constructed to start testing need a plan Testing strategy will only succeed if you: ○ Specify product requirements in quantifiable manner ○ State testing objectives explicitly ○ Understand your end users and develop a profile for each user category ○ Develop a testing plan that emphasizes “rapid cycle testing” ○ Build “robust” software that is designed to test itself ○ Use effective technical reviews as filter prior to testing ○ Conduct technical reviews on test strategy and cases themselves ○ Develop a continuous improvement approach for the testing process Test cases can be recorded in online collab and knowledge management systems such as GitLab Wiki Test case docs should contain: ○ Brief description of test case ○ A pointer to requirement being tested ○ Expected output from the test case data/criteria for success ○ Indicate whether the test was passed/failed ○ Dates the test case was run ○ Room for comets about why a test may have failed How do we know we are done testing? Better to have more rigorous criteria for sufficient testing ○ Use statistical techniques to estimate the number and severity of issues remaining in the software and use these statistical models to help determine when testing is completed Test Case Design Attributes of a good test ○ Has high probability of finding an error ○ Not redundant ○ Should be “best of breed” ○ Be neither too simple nor too complex 2 approaches to testing ○ Black Box/functional/behavioural testing Based on requirements from usage scenarios, rather than knowledge of internal control structures Uses end user visible inputs and observable outputs Focuses on functional requirements Tends to be applied during later stages of testing ○ White box/glass box/structural testing Uses implementation knowledge of control structures Can only be done once source code exists Aims to test all independent paths w/in a module at least once Important data structure

Software Engineering Notes PDF

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue