Skip to main content

Software Design and Architecture

 

 
         Architecture is the stuff that is really, really hard to change later.
 

  • Design (The Small Stuff): Choosing whether to use a for loop or a while loop. If you mess this up, you can fix it in 10 seconds. Design is the noun (the plan) and the verb (the thinking process) of arranging your components. 

  • Architecture (The Big Stuff): Deciding to use a specific database or deciding how your app talks to the internet. If you mess this up and realize it a year later, you might have to delete everything and start over.

     

     1.  SRS (Software Requirement Specification)
     
    The SRS is the contract. It describes the features. If it is written in the SRS, the software must do it. If it is not in the SRS, the software will not do it. 

      2. NFR (Non-Functional Requirements)

    NFRs do not describe what the software does (features). They describe how well it does it. We call these the "ilities": Reliability, Scalability, Usability. 

     

     Training Usability (The "Grandma Test")
    "How easy is it to learn?"
     This measures how long it takes a brand-new user to figure out how to do their job without asking for help.
     
    2. Operational Usability (The "Stress Test")
    "How does it behave under pressure?"
    Training usability is about the first time you use it. Operational usability is about the thousandth time you use it. It focuses on efficiency and speed when the user is an expert.
     
    3. Thresholds (The "Pass/Fail" Bar)
    "Where do we draw the line?"
    This is the most critical concept for an Engineer. You must define a specific number (a threshold) where "Good" turns into "Bad." If you don't set a threshold, you can't fail the software.
     
    Summary of Module 5
    1. Be an Engineer, not a Coder: Be Systematic, Disciplined, and Quantifiable.
    2. Respect the Order: Don't code before you design. Don't design before you know the requirements.
    3. Design in Layers: Start with the data (Storage), then the structure (Architecture), then the look (Interface), and finally the logic (Component).
     
     
     
     
     
     
     

     

     

     

     

 
Labels:

Comments

Post a Comment

Popular posts from this blog

Java Servlets

  According to me its just a translator, who manages the HTTP requests and handle them to the appropriate function of the API. So then, API turns out to be a term or set of those functions which are kept public. Now let us see in little bit of detail what servlets are: For that we need to see few terms: Static Web Pages: Static web pages are the pages, which are already built, and whose content and design always remain the same.  For Example: About us page of some website. Contact info page of some website Dynamic Web Pages: Dynamic pages are not already defined. They are dependent on search queries. For Example: If we search top 5 books, and click on search button, result would be different. If we search top 5 countries and enter search, result would be different.  So, the search result for every search is different. Working: Now if we have to search static page let's say the first page of any website (which is same for every use in every country) then the process is sim...
Post a Comment
Read more

OnClick and {}

1. The onClick Mystery: Is it the same? Yes, the concept is 90% the same. If you know how to handle a click in plain HTML/JavaScript, you already know how to do it in React. The logic flow is identical: Event: A user does something (Click). Listener: The element hears it ( onClick ). Handler: A specific function runs to deal with it. The "React Twist" (The 10% difference): There are two tiny syntax differences you must memorize: CamelCase: In HTML, it is onclick (lowercase). In React, it is onClick (camelCase). Function, not String: HTML (Old): onclick="doSomething()" (A string of code). React (New): onClick={doSomething} (Passing the actual function itself). So yes, your intuition is correct: Whenever you need to handle logic (clicks, hovers, typing), you will stick to this pattern: on[Event]={functionName} . 2. The Curly Braces { } : The Portal This is the most important syntax rule in JSX. Imagine your code file has two "Modes": HTML Mode: W...
Post a Comment
Read more

Servlet Context and Servlet Config

  Problem without init-parameters? Imagine you write a servlet that connects to a database. If you write the database URL, username, and password directly in your Java code, you have a big problem: What if the database password changes? You have to find the code, change it, recompile the .java file into a .class file, and redeploy the entire application. What if you want to use the same servlet in a different project with a different database? You can't. The code is stuck with the old settings. This is where init parameters come in. They let you move this configuration data out of your code and into the deployment descriptor ( web.xml file). How init-parameters help when we use them in web.xml file? They help us in a way that we don't have to find that particular part of code to change it. And also, it saves us the hectic of changing source code and recompiling that again. Anyone with .war file can change the web.xml file  and use it with class file without having the ne...
Post a Comment
Read more