Software Engineering.md

Software Engineering.md

Traditional Software vs Web-Apps

1. Computer Software used to be a product (sold in CD's , etc) where the people themselves own the software, now it's majorly distributed through the web
2. This means, the web version will always be up to date without the customer needing to do any manual work

What's Software?

Software can be seen as a

Product:

1. It enables us to make productive use of the computer hardware of our system and other connected systems
2. The main purpose of a software is to deal with creating, sending, modifying, analyzing information
3. This information can be as simple as a couple of numbers or can be as complex as the bits that build the buffer for streaming media
4. This is important because, the world right now is built on information, businesses need information and it's analysis, customers need information, schools need information, etc

Vehicle for delivering the product:

1. This usually involves, things that help run a software such as
   1. An Operating System
   2. The Network (Internet)
2. It also includes the tools that are used for building software
   1. IDE's, compilers, etc

Formal Definition

Software is

1. instructions that when executed provide the desired output
2. have data structures that properly manipulate information
3. a document stating the functions of the software and how to use software

Software vs Hardware:

1. Software is not "manufactured" (i.e, on an assembly line), it is engineered logically. The failure rate for hardware and software look like this

![[Pasted image 20231024082141.png]]

![[Pasted image 20231024082155.png]]

2. As we start, both hardware and software will have high failure (due to bugs), but as we reach the end, hardware tends to wear out which creates this "bathtub" curve for hardware
3. Software, on the other hand, never wears out, so it should ideally be a flattening curve, but solving one bug creates another and etc etc, so it's a little bit above the ideal curve
4. Hardware has standardized components (screws, pipes, etc) but software has a lot more freedom on it's structure and can be custom built

Types of Software

1. System Software - Operating System, Compilers, Software, drivers, etc ) - Software that facilitates other software running
2. Application Software - It's in the name, it's used for a SPECIFIC APPLICATION (business need) - (software for analysing business data, etc)
3. Product-line Software - Software that can be sold as a "product" to a wide range of consumers (Microsoft Excel, Microsoft word, etc)
4. Embedded Software - A very small piece of software that is embedded inside a machine (washing machine, oven, etc) that helps the machine to function
5. Scientific/Engineering Software - built for specific engineering / scientific needs
6. Web Apps
7. AI Software

Legacy Software

1. Software that was built decades ago but is STILL important and in use
2. Why legacy software is hard to maintain:
   1. No proper documentation
   2. No change history
   3. old coding patterns
   4. Code that is hard to change
3. The solution to this is If it works don't fix it
4. Legacy software is only put out of use if the change is too big and the entire software has to be built from scratch again

Characteristics of WebApps

1. Continuous Evolution - Always on the latest version
2. Unpredictable Load
3. Network Dependency - The WebApp resides on a network
4. Availability - Since the webapp is not in your system, it's availability is dependent on the servers
5. Aesthetics - It has to look good
6. Content Sensitivity - The main thing about a web-app is the content it provides
7. Concurrency - Many people can access the same app at the same time (have to manage the load)
8. Data Driven
9. Immediacy (Fast distribution) - compared to selling product software on CD's, distributing websites is very fast as you only need to share the URL
10. Security - preventing DDoS, and other stuff, since we don't know how many people are accessing our website and how many are trying to hack our website
11. Performance - the website has to load fast

Why Software Engineering?

1. Software has grown into every field possible, this means there's more and more demand for GOOD software to be built
2. the reliability on software is very high and requirements are complex
3. Not just building the software, since the demands of the people change over time, the software has to evolve and has to be maintainable
4. it is important that we follow a framework that helps to build quality software, in less time and without bugs
5. Such framework is called "Software Engineering"

Formal Definition:

1. The application of a systematic, disciplined and quantifiable approach to build, operate and maintain software
2. Thus, application of Engineering Principles to Software

Layers of Software Engineering

Software engineering is best understood in multiple layers, where one layer builds on top of another

![[Pasted image 20231024090914.png]]

Quality Focus:

1. Not just software, any engineering approach must have quality as it's highest priority

Process:

1. The Software process focuses on helping people to manage the entire Software Project in a broad sense
2. It focuses on creating work products (models, documents, data, forms, reports, etc)
3. It focuses on maintaining quality
4. It focuses on setting milestones

To be simple, it's sorta for managers to manage the project at a high level and make sure it's heading in the right direction

Methods:

1. The SE Methods provide technical to-do's
2. These are usually handled by the engineers, designers, etc
3. It focuses on creating Models, Gathering Requirements, Testing, Program Construction, and a lot more technical stuff

Tools:

1. The Tools that help facilitate these Processes and Models are known as SE tools
2. If these tools are being used, then SE can be referred to as Computer Aided Software Engineering

Software Process

Any Software Process consists of:

1. Activities - Activity is something that you do to achieve a very "broad" objective (not clearly defined objective) - Communicating with stakeholders. They can usually be applied to any software project
2. Actions - They are a set of tasks that result in a major work product - (architectural design)
3. Tasks - A miniscule unit of work that results in a tangible outcome

SE Process is just a step by step following of Activities

Activities are divided to Actions which are divided to Tasks

Obviously, all software do not follow the same process, that's why we have process frameworks

A process framework consists of basic activities that can be applied to any software project

Here's a simple 5-step(activity) process framework:

1. Communication
2. Planning
3. Modeling
4. Construction
5. Deployment

Umbrella Activities:

A couple extra activities that can be applied anywhere in the SE Process

1. Risk Management
2. Technical Reviews
3. Reusability Management
4. Quality Assurance, etc

Once these activities are sequenced, they can be applied step-by-step, or iteratively

iterative application is when you do one activity multiple times before moving to the next activity

Process Models:

Process Models describe how to "model" / "create" a new process for your software project

A few of them are :

1. Prescriptive process model
2. Agile process model

Software Engineering Principles

Principles are an underlying "law" that should be kept in mind while using Software engineering

1. Reason - The main focus should be "why is this software being built? is it of actual value?"
2. KISS - everything should be made as simple as possible
3. Plan for future - make your code extensible / easier to maintain
4. Keep others in mind - your code will be read by others (what you produce others will consume)
5. Plan for reuse - reusing components is always better
6. Maintain vision - two or more people can have conflicting views, they've to be maintained by a software architect
7. Think - think before doing anything

Software Myths

Manager Myths

1. Adding more programmers doesn't mean project is finished quicker - takes time for KT
2. Just outsource everything to a third party - the 3rd party doesn't understand our code!

Client Myths

1. Giving a general statement about the project is enough to start writing code - NO!
2. Software requirements changing is easy - NO!

Practitioner Myths

1. After the code is written my job is done - no! you have to maintain it
2. i cannot test a program until i run it - no! you have technical reviews, etc
3. code is the only output (work product) of a software project - no! work products can include, documentation, and a lot of other stuff'
4. software engineering slows us down - not in the long term

Software Process

1. Steps that are taken to build a software, these steps are Activities, which contains of Actions which contain of Tasks

![[Pasted image 20231024103938.png]]

2. A process model helps us to create/model a new process for our software project

Process Flow

Describes how the activities of a Software Engineering Process are ordered and executed

1. Linear Process Flow - each activity is executed only once and moved to next activity
2. Iterative Process Flow - each activity can be executed one or more times before moving to the next one
3. Evolutionary Process Flow - activities are executed in a circular manner, and with each cycle the software is evolved
4. Parallel Process Flow - one or more activities are executed in parallel

![[Pasted image 20231024104908.png]]

To execute an activity:

1. Define the actions that this activity encompasses
2. Define the task sets for each action

Process Patterns

Process patterns describe a process-related problem provide a tested solution for that problem

This is done so that whenever a similar problem is encountered in the future, an already tested solution can be applied

Template for process pattern:

1. Pattern Name - "RequirementsUnclear"
2. Forces - Environment in which the pattern is encountered
3. Type - a process pattern can be of 3 types
   1. Stage Pattern - Problem associated with a single activity - EstablishingCommunication
   2. Task Pattern - Problem associated with a task or an action - RequirementsGathering
   3. Phase Pattern - Problem associated with a sequence of activities or the entire process
4. Initial Context - Describes what should've happened before the pattern, 1) what activities are already finished, 2) what info do we already have
5. Problem - the specific problem to be solved
6. Solution - description on how to solve this problem
7. Resulting Context - describes how the result will be ONCE the pattern has been applied
8. Related Patterns

Process Assessment

Just because we have a software process, doesn't mean that we will certainly finish it on time and satisfy the customer's needs

This means, a Process has to be "Assessed" to make sure it's suitable for our project

Prescriptive Process Models:

It's a collection of process models that "prescribe" how a new process should be modelled

Each of these process models also prescribe a process flow

Waterfall Model:

![[Pasted image 20231024113112.png]]

1. This process model can be used for projects which are simple and well-defined from the start
2. It has a linear process flow
3. The activities are simple, and are same as the generic process model (comm, plan, modl, const, depl)

V-Model (waterfall model variant)

![[Pasted image 20231024113453.png]]

1. This model first does design and coding and then does testing at the end
2. it's still linear process flow, just a different way of viewing it

Disadvantages

1. Real life projects almost never follow linear process flow (there's always requirements changing and new stuff being added)
2. Working version not available until the end
3. Very old, rarely used anymore

Incremental Process Model

![[Pasted image 20231024113731.png]]

Considering the disadvantages of Waterfall model, this process model was developed

1. The final product is divided into multiple increments
2. The first increment is a core product and features are added on top of it one by one
3. This way, an operational product can be shown to the client quickly and updates can be given

Evolutionary Process Models

To be brief, these types process models, build a not-so-good (rough/ugly/slow/inefficient) version of the software completely and then evolve it to be faster / better

Prototyping Process Model:

![[Pasted image 20231024114157.png]]

In each cycle, a better prototype is being built

This process model also enables for a feedback loop (based on the feedback of the last prototype the newer prototype can be built better)

Advantages:

1. Clients can see the working version quickly
2. Every new prototype is optimized (code-wise) / better than the last prototype

Spiral Model

![[Pasted image 20231024114500.png]]

It's a more "complete" version of the prototype model (mostly similar, but it's well defined)

After each circuit (loop) a new prototype is built

It's a combination of iterative and prototype model

Disadvantages of Evolutionary Process Models

1. Can't predict the number of prototypes to reach final product
2. doesn't describe the size / pace of an evolution
3. too much focus on improving / optimizing the quality

Specialized Process Models

1. As the name suggests, can only be used in very specific software projects
2. It combines one or more traditional process models

Component-Based Development

1. Many vendors offer commercial , pre-existing components that can be directly used in our software project
2. It has the following steps implemented iteratively
   1. Available components are researched specific to application
   2. Integration issues are considered
   3. A software architecture is designed to accommodate components
   4. Components are integrated
   5. Testing Advantages - 1) Reuse 2) Faster development\

Formal Methods Model

1. Everything is formally/"mathematically" verified
2. Helps in reducing code ambiguity, inconsistency and makes the code defect-free
3. It's time consuming and expensive but offers defect free software
4. Software Developers need to have the mathematical background to apply these methods
5. difficult to communicate with customer

Aspect-Oriented Software Development

Aspect - this is code that is required to be in many functions (cross-cutting) , so this code is written as a separate module

1. These days the software is so complex that customer wants to control not just the surface layer of the software program, but also how certain things are done at functional level ( memory management, etc)
2. To accommodate this, we need AOSD, (asp orient softw dvlpmnt)
3. This process model helps us to create a process that defines all the aspects that the client requires
4. It's a new model

Unified Process Model

It takes the best parts of traditional process models and "unifies" them to match the need of modern software projects

In brief, it suggest a process flow that is iterative, incremental and evolutionary

This process model is suggested by the same people who created UML for modelling & developing object-oriented systems

Unified process & UML are both widely used today for OO systems

![[Pasted image 20231024121935.png]]

1. UP is made of phases which are similar to activities
2. The above diagram relates UP phases to Generic Process Model activities
3. UP Phases:
   1. Inception:
      1. Contains both customer communication and planning activities
      2. By communicating with the clients, business requirements are identified and a rough architecture is made
      3. The business requirements are described through use cases
      4. The architecture right now is nothing more than the description of major subsystems and the type of users that will populate them and features required
   2. Elaboration:
      1. Contains both the planning and modelling activities of Gen. Prcs Modl
      2. It expands upon the use cases that were gathered in inception phase and draws 5 views of the software (modeling):
         1. UseCase Model, requirements model, design model, etc
   3. Construction:
      1. Same as the Construction Activity of Gen prcs mdl
      2. Using the architectural models, the construction phase develops the software and tests it parallelly
   4. Transition:
      1. In this stage, the transition is between later stages of construction and early stages of deployment
      2. Things like beta testing and user feedback are done here
   5. Production:
      1. At the later stages of deployment while the latest release is being monitored, the work for the next increment can also be started

Personal Software Process

1. Each member of the team follows their own process and takes up self responsibility and plans on their own
2. Harder to implement because each team member has to be disciplined and must stick to this model
3. NOT USED WIDELY

Activities of this process model:

1. Planning - make estimations and plan development tasks
2. High Level design - Each component is given external specifications and is designed
3. HLD Review - formal metric based approach is used to review HLD
4. Development - code is generated & compiled
5. Postmortem - Testing the development and metrics to refine the process for next iteration

Team Software Process

1. Each TEAM follows their own process and takes up responsibility without a manager (Self directed team)

2. It's an extension of PSP but for teams

3. This process model has following activities:

4. Project Launch

5. High Level Design

6. Implementation

7. Integration

8. Testing

9. Postmortem

Agility

1. Effective response to change ( change in requirements, change in team, etc)
2. Adopts customer as a part of the team
3. Very flexible ( older prescriptive process models relied a lot on discipline )
4. Only essential work products
5. does not emphasize on un-necessary documentation
6. encompasses incremental delivery of operational software

Cost of change in Agile Processes

![[Pasted image 20231024160512.png]]

1. In a conventional software process, if some change is to be made but the project is at a later stage (let's say, testing). all the steps have to be re-done and this increases the cost of the project significantly
2. Whereas, agile processes use incremental delivery, continuous testing, etc to "flatten" the cost of change curve

Why we need Agile Processes

1. Difficult to predict change
2. Design and construction are interleaved (it's not practical to design the entire thing first and then do construction)
3. We cannot predict everything in planning phase

AGILITY PRINCIPLES

1. Customer is first priority
2. Customer works as a part of the team
3. Incremental working software should be delivered frequently
4. The progress is measured by final working software
5. Welcome changes in the project (even at later stages)
6. Face to face communication is important
7. Sustainable development - constant pace
8. Attention to technical excellence and good design
9. Focus on simplicity
10. self organizing teams
11. Build projects around motivated individuals
12. Reflect on how to become more effective

Characteristics of people working in Agile team

1. Competence - knowledge and talent
2. Common focus - they might be working on different things, but their main focus should be to deliver the next software increment
3. Mutual respect - respect and trust each other in a team
4. Collaboration - must be able to collaborate efficiently
5. Decision making
6. Fuzzy problem solving - should be able to solve ambiguous/uncertain problems that might arise
7. Self organization - setting deadlines for themselves, etc

Extreme Programming (XP):

Most widely used approach to agile process

XP Software is built on Object Oriented Paradigm

It is built upon 5 values

1. Communication - Keep communication between developers and customers simple, instead of communicating through huge lines of documentation, XP suggests to use "metaphors" (stories and use cases) that help get the message across the board
2. Simplicity - Do not consider future needs, only consider immediate needs, if they change in the future, it'll be handled in the future only
3. Feedback - Three ways of receiving feedback:
   1. Customer
   2. The Software itself
   3. Unit testing - the tests are designed to check if the stories/use cases described are working
4. Courage (Discipline)
5. Respect

XP Process:

It consists of 4 activities

![[Pasted image 20231024164540.png]]

1. Planning:
   1. Collecting data from the customer as "stories" or "user stories"
   2. The customer then assigns value to each user story which gives it a priority
   3. Then, the XP Team and Customer both come to a commitment indicating:
      1. Stories to be included in next release
      2. Development time
      3. Cost
   4. After this, the XP team arranges the stories in one of following ways:
      1. Immediately implement all stories
      2. Sort based on value
      3. Sort based on risk ( high risk implmntd first )
   5. In the next iteration, the customer can add stories/remove stories, etc and the team adjusts accordingly
2. Design:
   1. XP focuses more on code and less on design, so only CRC Cards are used
   2. If a design problem is too complex to be represented by CRC cards, a small prototype should be implemented immediately (this is known as a spike solution)
   3. Design is refactored frequently
3. Coding:
   1. Before coding, the Unit tests are written firstl according to the stories
   2. Then, the code is simply written to pass the unit tests. This way, only what's necessary is written
   3. Pair Programming - two people sit together at a single workstation and create code for a story, one person might think about the coding details, while the other ensures that XP standards are being followed, etc
   4. Continuous Integration - As the pair complete their work, the code should be integrated with the code of the others.
4. Testing:
   1. Unit tests are critical component of XP approach
   2. They should be automated and these tests should be continuous

Industrial XP:

It's an evolution of XP for VERY LARGE PROJECTS in LARGE organizations

1. Readiness Assessment - check if the organization is big enough and can be populated with sufficient people, has proper stakeholders, sponsors, etc
2. Project Community - since IXP is implemented on a huge scale, the concept of an 'Agile Team' is changed to that of a "community"
3. Test Driven Management - to get an idea of the progress in a software project, the tests passed are considered as a metric
4. Retrospective - after each software increment, a review is conducted and improvements in the process are discussed
5. Continuous Learning

Criticisms of XP

1. Since we are not maintain documentation, requirements are discussed informally
2. Conflicting customer needs are hard to handle
3. No FORMAL DESIGN (only crc's are used)

Other Agile Process Models

Adaptive Software Development (ASD):

Main focus on Human Collaboration

![[Pasted image 20231024180233.png]]

The image describes everything

Scrum

Fun Fact: Scrum is the same as a rugby scrum

![[Pasted image 20231024180437.png]]

1. Work Tasks in each activity is divided into sprints
2. The number of sprints for each activity is hugely variable
3. The Scrum software process flow contains the following
   1. Backlog - List of project requirements/features that is sorted based on priority
   2. Sprints - work units to achieve a requirement defined in backlog, these must fit into a predefined timebox(30days )
   3. Scrum meetings - three key questions asked
      1. What'd you do since last team meeting?
      2. Obstacles encountered
      3. Things to accomplish by next team meeting
      4. Scrum Master leads the meeting and asses each person's responses
   4. Demo - deliver the software increment to customer

Dynamic Systems Development Method

1. Used in situations with tight time constraints
2. It works by rapidly building prototypes of the project and then, based on the time left, improving that prototype
3. Based on the pareto's principle

DSDM has following activities and iterations

1. Feasibility study - check the amount of time left, and the business requirements and find out if the project suits DSDM

2. Business study - identify the core requirements of the project that will give it business value

3. Functional Model Iteration - each iteration produces a functional model to demo to the customer

4. Design and build iteration - revisits prototypes built during previous iteration check whether they've been engineering properly

5. Implementation - put the software increment in an operational environment

Crystal

Family of agile process models that can be adapted to many projects

Feature Driven Development

practical process model for Object oriented projects

Features are considered as "small blocks of deliverable functionality that the client values and can be delivered in 2 weeks"

The team develops operational features every 2 weeks, the features developed are how we measure the progress of a project

![[Pasted image 20231024182540.png]]

Lean Software Development

The main principles of LSD are :

1. eliminate waste - do not add extra features
2. build quality
3. defer commitment
4. deliver fast
5. respect people
6. optimize everything

Agile Modeling

It's not a software process model, it's a way of building models (like UML) but it follows agile principles like keeping it simple, not doing anything extra, and embracing changes

Principles of AM:

1. Model with purpose - Why are we modelling? to provide information to customer so that he can better understand the software
2. Use multiple models - each model should describe a different aspect of system, and suitable models should be picked for each part of system
3. Travel light - keep only those models which you need
4. Focus on content - do not forget that you're modelling to give information, not for fancy representation
5. Understand Models & tools
6. Adapt locally

Agile Unified Process

Just like UML has UP, AM as AUP

AUP extends the principles of Unified Process and uses agile principles in it

Each AUP iteration has following activities

1. Modeling - UML representation are created (just good enough)
2. Implementation
3. Testing
4. Deployment
5. Configuration & Project Management - addresses change management/risk management
6. Environment Management - process infrastructure that includes tools, other support technology for the team

Understanding Requirements

It's very important to understand the requirements from a client's perspective properly, before even moving on to writing code

Understanding the client's requirements is something that needs to be done in a structured and organized manner to make sure that we don't miss out on any requirements

Requirements are collected from customers and users

That's why we have, Requirements Engineering

Requirements Engineering

1. The broad spectrum of tasks and techniques that lead to developing an understanding of the requirements is called requirements engineering
2. It helps in:
   1. Understanding what customer wants
   2. Analyzing the needs
   3. checking feasibility
   4. negotiating a solution
   5. validating specification
   6. managing requirements, etc
3. From a Software Process perspective, Requirement Engineering is an action that takes place between communication and planning activities

Tasks that make up requirement engineering

1. Inception
   1. this task is when the idea is newly formed, or when a business need is identified.
   2. Stakeholders from the business community analyze the need, calculate feasibility and try to get a working description of the project that is required
   3. In this stage, you only get a basic idea of what's required in a software project, what is the problem being solved, etc
2. Elicitation
   1. definition: to extract information out from someone
   2. Not that simple as it sounds, due to following reasons
      1. Most of the times client is not clear with requirements, do not understand the limitations of tech
      2. requirements keep changing
      3. customers specify unnecessary technical detail that causes confusion
3. Elaboration
   1. The information collected in Inception and elicitation is elaborated
   2. In this stage, requirements model is created based on the user scenarios collected in the above phases
   3. Each user scenario is parsed to create Analysis classes and relationship between these classes are identified
4. Negotiation
   1. It is obvious that a customer is going to ask for more requirements than the budget of the project
   2. These situations are to be handled using negotiation in such a way that in the end all the parties are satisfied
   3. These could include discussing requirements again, modifying or eliminating them.
5. Specification
   1. Specification is where all this information collected/analyzed is supposed to be written in
   2. This can include diagrams, user scenarios, etc
6. Validation
   1. In this stage, the specification is validated to make sure that there are no inconsistencies
   2. The review team includes software engineers , customers , users and all the other stakeholders
   3. They discuss conflicting requirements, unrealistic requirements
7. Management
   1. This step handles changes in requirements
   2. Requirements management is a set of activities to help track requirement and changes to requirements

Requirements Engineering - Inception

1. Identifying Stakeholders -
   1. people who are qualified and whose input is required to understand project requirements
   2. ex: marketing people, business folks, support engineers, customers, etc
2. Recognizing Multiple Viewpoints -
   1. Each stakeholder is bound to have multiple, and sometimes conflicting viewpoints
   2. Example: business folks are focused on budget, marketing folks want to add new attractive features, customer wants easy to use interface, etc
   3. Each of these viewpoints must be recorder properly so that a decision can be taken later
3. Collaboration -
   1. Since multiple stakeholders are involved in a software project, as discussed above, they have multiple view points
   2. these can be solved by having these stakeholders collaborate (directly or indirectly) and reach a common solution
   3. In the end, a "project champion" (business manager) takes the final call
4. Asking first questions -
   1. The questions to be asked are divided into three parts:
      1. to identify stakeholders -
         1. Who requested this work?
         2. Who'll use the solution?
      2. talk to stakeholder to understand problem -
         1. What's the expected output?
         2. What problem does this solve?
         3. Do you have any special performance issues or constraints?
      3. meta questions on communication itself -
         1. Are your answers official?
         2. Am i asking too many questions?
         3. Should i ask someone else?

Requirements Engineering - Elicitation

1. Collaborative Requirements Gathering -
   1. Meetings are conducted to be attended by both stakeholders and engineers
   2. Rules are established
   3. A facilitator controls the meeting
   4. The entire project is divided into objects and solutions are proposed by each participant in the meeting
   5. These solutions are later combined and refined to get a good idea of the project requirements
   6. This is converted to detailed specification later
2. Quality Function Deployment (QFD)
   1. QFD is a quality management technique that translates customer needs to technical requirements
   2. It divides the requirements into three categories:
      1. Normal Requirements - discussed with customer
      2. Expected Requirements - implicit
      3. Exciting - beyond customer's expectations
3. Usage Scenarios -
   1. They are user stories (use cases) that describe how a user interacts with the system

Work Products - Elicitation:

After elicitation, the following work products can be expected:

1. A list of stakeholders
2. A list of requirements
3. Description of technical environment
4. Set of usage scenarios
5. Optional prototypes

Building Use Cases

The user stories that were discussed in elicitation meetings have to be converted to use cases

Note: Use cases are written with end user in mind

Terms to know:

1. Actor - anything external to the system that interacts with it
   1. Primary Actor - interact directly with the system to achieve desired function
   2. Secondary Actor - they support the system so that the task requested by primary actor can be completed

Format of a Use Case Description:

1. UseCase - InitiateMonitoring
2. Primary actor
3. Goal in context - what the use case is trying to accomplish
4. Preconditions - conditions that must be true for this use case to occur
5. Trigger - what starts this use case
6. Scenario - step by step description of the use case story
7. Exceptions - things that might go wrong when the scenario(story) is happening
8. Priority
9. Available when? - third release
10. Frequency of use - many times a day
11. Channel to actor - how can primary actor interact with this use case
12. Secondary Actors
13. Channel to sec. actors
14. Open Issues

Requirements Engineering - Building Requirements Model

Requirements model is a graphical representation of functional, behavioral and informational domains that describe requirements

It's synonymous to analysis model

What requirements model should contain?

1. User Scenario based elements
   1. Using the scenarios collected before, things like Use Case Diagrams and Use Case Descriptions, etc can be drawn
2. Class Based Elements
   1. On going through the Use Case Diagrams, we can observe a set of objects that are manipulated as the actor interacts with the system
   2. These objects are identified and class diagrams that represent their attributes, methods, etc are drawn
   3. Later, there can be diagrams drawn that depict how these classes interact with each other
3. Behavioral elements
   1. There have to be modelling diagrams that depict the behavior of the system (state diagrams, etc)
4. Flow oriented elements
   1. Depicts how information is transformed as it flows

Analysis Patterns:

The requirements model typically contains analysis pattern that describes previous problems that we ran into while building an analysis model

Requirements Engineering - Negotiating Requirements

1. It should always end in a "win-win" situation for all the parties involved
2. Identify key stakeholders
3. Determine what they exactly want
4. Reconcile everyone so that each party is benefitted

Requirements Engineering - Validating Requirements

It is important to examine requirements for inconsistencies , ambiguity and omissions

The following questions can be asked:

1. are requirements consistent?
2. is each requirement described well enough ?
3. is this requirement necessary?
4. are any requirements conflicting?
5. can i test this requirement?
6. does the requirement model match the requirements?

Objectives of Requirements Model

1. Describe what the customer requires
2. Establish a basis for creation of software design
3. Define a set of requirements that can be validated once the project is finished

Principles while building requirements model

1. Model should focus on visible requirements (don't go too much into detail)
2. Non functional stuff should be saved for last
3. Keep it simple
4. Make sure that this model represents all stakeholders points of view
5. Each element should add understanding of the requirements (no redundant elements)
6. Minimize coupling in system

Domain Analysis

1. Different software domains already have "analysis patterns" based on previous projects
2. So, Domain Analysis is:
   1. Identifying the domain of the current software project
   2. collect all the analysis patterns for that domain
   3. reuse these analysis patterns wherever applicable

Scenario Based Modeling

Use cases are developed in three stages

1. Creating a Preliminary Use Case
   1. The inception and elicitation tasks provide with enough information to start writing use cases
   2. list the functions performed by a specific actor like a story
2. Refining this use case
   1. Analyze each step in this use case and figure out alternative actions that user can take
   2. think about exceptions that might occur when system behaves unexpectedly
3. Writing a formal use case
   1. Same format as described above in Formal use case format

UML Models for supplementing the use case

1. Activity Diagram - graphical representation of the flow of actions in use case (sorta like control flow of a program)
2. Swimlane Diagram - alternative of activity diagram

Class-Based Modeling

Identify the objects that are part of the user story, and build class diagrams for them!

Class-based model includes:

1. Classes & Objects - attributes, methods, etc
2. CRC (class responsibility collaborator ) models
3. collaboration diagrams
4. packages, etc

To do class-based modeling for a project, here's the steps that need to be followed

Identifying Classes

1. look through the user scenarios in a grammatical sense and identify all the "nouns"
2. Categorize these nouns as one of the following:
   1. External entities - other systems that produce/consume information from our system
   2. Things - part of information domain (reports, letters)
   3. Events
   4. Roles - roles of the actors
   5. Places - physical places
   6. Structures - sensors, vehicles, etc
3. These nouns are further filtered into a "class" only if these 6 criteria are met
   1. Retained Information - the class needs to retain information
   2. Needed services - the methods must change the attributes in some way
   3. Multiple attributes - the class should have more than one attribute
   4. Common Attributes & Common Operations - try to find these to make use of inheritance
   5. Essential Requirements - having this class is absolutely essential (for eg, classes for interacting with external entitites)

Specifying Attributes

1. study each use case and select those "things" that "belong" to this class
2. "what data items fully define this class in the context of current problem"

Defining Operations

1. they define the behavior of an object
2. they are divided into 4 categories:
   1. operations that manipulate data (CRUD)
   2. operations that perform a computation
   3. operations that inquire about the state of an object
   4. operations that monitor another object for an event (even listener)
3. go through the use cases and find out verbs
4. divide operations into sub operations wherever you see fit
5. consider communication that occurs between objects

CRC Modeling

1. CRC Models is a collection of index cards where :
   1. Class Name is on top
   2. Class responsibilities are written on left
   3. Class Collaborator are on right

![[Pasted image 20231025135447.png]]

Responsibility - anything that a class knows / does Collaborators - classes that are required for the current class to fulfill it's responsibility

Classes are divided into three types:

1. Entity classes - which represent an actual entity in a project
2. Boundary classes - act as an interface between the user and the system
3. Controller classes - manage the creation/deletion of entity classes and a lot more activities

Guidelines for allocating responsibilities to classes:

1. Responsibilities should be equally divided among classes
2. Information and behavior should reside in the same class
3. Information should be present in one class only (no duplicates)

Guidelines for allocating collaborators to responsibilities

1. If a class cannot fulfill the responsibility on it's own, it can collaborate with other classes in a "client/server fashion"
2. To find out the collaborators of a class try to get the relationship between classes (is part of , depends on ,etc)

Reviewing CRC cards:

1. All participants are given subset of CRC cards (no participant gets two cards that collaborate)
2. All use cases are given to participants
3. Review Leader reads the use case line by line, as soon as the object name comes up, the person who is having that crc card should now speak
4. the person having the crc card is asked to describe the responsibilities of the card, everyone now checks if the situation described in the use case can be satisfied by one of the responsibilities mentioned in the CRC card
5. if it doesn't match, they're revised again

Associations and Dependencies between Classes

When we say, what's the relationship between two classes, "association" should come to our mind

![[Pasted image 20231025141107.png]]

In the above example, the relationship between classes can be written as

1. Wall Segment is used to build Wall ,
2. Door is used to build wall

Association can be extended by providing multiplicity (number of instances of that class)

Notice the above diagram and identify multiplicity :

1. Between wall and door, there can be 1 wall with 0 or more doors

Dependency is when one class needs another class to fulfill a responsibility (kinda like how a client needs a server) :

![[Pasted image 20231025141819.png]]

Here, Display Window is dependent on Camera class

Analysis Packages

Package - a collection of related classes

![[Pasted image 20231025141928.png]]

Behavioral Model

Behavior - how the system should react(behave) or respond to external events or stimuli

Steps for creating behavioral model:

1. Read through use cases and understand sequences of interaction
2. Identify events that are a part of interaction sequence, and figure out how these relate to objects
3. Create a sequence for each use case
4. Build a state diagram
5. Review the correctness of the model built

Identifying Events in use case

1. event occurs when an actor and system exchange information
2. examine the use case to find points of information exchange
3. after identifying events, allocate them to respective objects

State Representation

There are two types of states:

1. State of each class
2. State of the entire system from the outside

It is possible to argue that the state of a class is simply the value of attributes of THAT class, but this type of state is passive state

Active state represents the process that the class is currently going through (verb)

State Diagrams for Analysis Classes

1. UML state diagram represents active states of each class and the events that can change this state

![[Pasted image 20231025152712.png]]

These are useful to have a view about the lifecycle of an object

Sequence Diagrams

It indicates how events transition from one object to another

![[Pasted image 20231025153533.png]]

Using the data from sequence diagram, one can easily combine all the incoming events and outgoing events from each object to get an idea of all events.

Requirements Modeling

Patterns - reuse ideas and solutions that have already been applied and tested before

Patterns for requirement modeling contain: 1) Classes 2) Functions 3) Behaviors, etc

These patterns are stored in the company repository for later use

The easiest way to look for an analysis pattern is to figure out its use cases and find a pattern with matching use cases

Such patterns are called Semantic Analysis Pattern (SAP) They contain a small set of use cases that make up a basic application

Software Design

Design is the last software engineering activity, and sets the stage for construction

![[Pasted image 20231025155355.png]]

1. Data/Class Design
   1. Takes class diagrams and designs concrete implementations of them (using appropriate data structures, etc)
2. Architectural Design
   1. Defines the relationships between elements of software
   2. The architectural styles that can be used in this design and how feasible is it's implementation
3. Interface Design
   1. Describes how software communicates with the outside components
   2. Usage scenarios & behavioral models provide information for interface design
4. Component-Level design
   1. Transforms architecture into description of loosely coupled software components

Software Design Quality Guidelines

1. design should be made from recognizable architectural styles
2. should be modular
3. should contain representations of data, architecture, interface and component as shown in the pyramid above
4. should contain appropriate data structures
5. components should be loosely coupled
6. interfaces should reduce complexity of connections]
7. design should have proper notation
8. design formation should be iterative

Design Concepts

There exist many philosophies for design but only a few fundamental design concepts are almost always used in any software project

1. Abstraction
   1. Abstraction is hiding complex details and stating the solution in broad terms
   2. two types of abstraction: Procedural (functions, etc) and Data abstraction
2. Architecture
   1. Represents the overall structure of the software and how they are conceptually integrated
   2. It also shows how the components interact, structure of data used by components, etc
   3. The following is part of architectural design:
      1. Structural Properties - the list of objects and how they interact
      2. Extra-functional properties(non functional) - description should address things like performance, reliability, etc that DO NOT affect functionality
3. Patterns:
   1. Conveys a proven solution to a problem encountered before
   2. Each pattern contains the following information
      1. In what context is this pattern applicable
      2. Can the pattern be reused
      3. Can this pattern be used to build similar patterns
4. Separation of concerns
   1. Any problem can be handled better if divided into pieces
   2. All components should be loosely coupled
5. Modularity
   1. It's a manifestation of Separation of concerns
   2. Modularity is the only thing that makes a software easier to understand than having to take the entire project in at once
   3. ![[Pasted image 20231025163606.png]]
   4. Modularity is only good upto a certain point after which the cost to integrate becomes higher
6. Information Hiding
   1. It builds upon modularity
   2. It says that each module should hide all it's information and only share what's absolutely necessary with other modules
7. Functional Independence
   1. Each Module handles only One functionality
   2. It should have a simple interface
   3. Independence can be calculated using two criteria
      1. Cohesion - each module should be simple and perform only one function
      2. Coupling - interconnection between modules should be as simple as possible
8. Refinement
   1. Top-down strategy where programs are developed by continuous refinement of detail
   2. This helps in iteratively building the design
9. Aspects
   1. Code that is required to be in multiple functions
   2. This is accomplished by creating a module that implements this functionality across multiple concerns (key word : cross cutting )
10. Refactoring
    1. Simplifies design of code WITHOUT changing behavior
11. Object Oriented Design Concepts:
12. Design class
    1. Just like the requirement model created a couple of analysis class, the design classes are an extension of these
    2. There are 5 types of design classes
       1. User Interface Classes - define all the classes that create an interface between the system and the user
       2. Business domain classes - they contain the business logic, they're almost always just refinements of analysis classes
       3. Process classes - abstraction over business classes
       4. Persistent classes - classes that handle data
       5. System classes - core classes that control the entire system
    3. Design classes reduce the abstraction in analysis classes
    4. 4 characteristics of a well formed design class:
       1. Complete and Sufficient
       2. Each class method should focus on providing one service only
       3. High cohesion - few related functionality in one class
       4. Low coupling

Design Model

The Design model contains of 4 elements

![[Pasted image 20231025173129.png]]

1. Architecture elements - Design classes, collaboration diagrams
2. Interface elements - User Interface (UI) , Navigation design, etc
3. Component elements - Component diagrams, design classes, activity diagrams, sequence diagrams
4. Deployment elements - Deployment diagrams

Data Design

1. Deals with planning how the data is structured through data models, etc
2. It helps in structuring the databases,
3. It also helps when business wants to analyze the data (data mining, etc)

Architectural Design

1. it's like the floor plan of a house
2. it depicts interconnected subsystems (often subsytem = analysis package)

Interface Design

1. it's like detailed drawing for doors/windows (interfacing with outside world)
2. Examples of interface: UI, API (external interface), internal interface, etc
3. UI involves:
   1. Using reusable components, UI patterns
   2. navigation
   3. layout
   4. placement, etc
4. External Interface:
   1. knowing about the entity to/from which we're trying to send/receive information
5. Internal Interface:
   1. Aligned with component-level design
   2. Deals with internal components talking to each other

Component level design

1. it's equivalent to detailed drawing & specification of EACH ROOM in a house
2. they describe all the places inside room, the flooring to be used, therefore it's exhaustive low-level details about the component

Deployment design

1. They indicate how these systems will be placed in physical computing environment (servers, local pc, cloud, datastores, etc)

![[Pasted image 20231025174247.png]]

Architecture Design

Architecture - describes the structure and form and how the components fit together and interact with each other

Design is an instance of Architecture (e.g, client-server architecture can have multiple designs)

why is architecture important?

1. it gives a small model of the structure of the system and how it's components work together
2. it helps in quickly making design decisions
3. it's easier to communicate with all stakeholders with the help of an architecture

Architectural Descriptions

1. architectural description is a collection of products to document an architecture (stuff that can document an architecture)
2. architecture has multiple views, where each view is tailored to different stakeholder
3. views are created according to rules specified by viewpoint

Architectural Genres

Groups software projects having similar architecture into genres, here's a few examples of architectural genres

1. AI
2. Commercial Non profit (business enterprise)
3. Communication
4. Content creation
5. Financial
6. Games
7. Legal
8. Medical
9. Operating Systems
10. Scientific

Architectural Styles

1. each architectural style gives a brief information about what the architecture will look like, it contains
   1. set of components
   2. set of connectors that connect these components
   3. how components are connected (brief)
   4. semantic models to help the designer understand system
2. Architectural Styles depict how each component will be designed like, whereas Architectural pattern depict how the entire architecture is designed like

Example Architectural Styles

1. Data-centered:
   1. Data store is at the center of this and is accessed by all components
   2. ![[Pasted image 20231025181844.png]]
   3. Components do not interact directly with each other, but through the central data store
   4. This style promotes integrability of the system
2. Data flow architecture
   1. Applied when input data is to be transformed into output data using a series of steps (Through a pipe)
   2. Each step is called as a "filter" , filter does not need to know about neighboring filters
   3. ![[Pasted image 20231025182037.png]]
3. Call and return architecture
   1. The main program calls sub programs, the sub program returns some data and this is used to continue the main program
   2. ![[Pasted image 20231025182129.png]]
4. Object oriented architecture
   1. Each object encapsulates data
   2. communication between objects is through passing messages
5. Layered architecture
   1. ![[Pasted image 20231025182221.png]]
   2. A number of layers are formed where each layer is dependent on the layer below it

Architectural Patterns

1. reusing already created architectures by trying to figure out the domain of this project and checking the company repository

Assessment of Design Architecture

1. How is control managed in this architecture (control flow)
2. How is data communicated between components