Design Models – Key Points Summary

 Role of Analysis Outputs in Design

o Documents and models from analysis (class diagrams, use cases, etc.) become
inputs for design.
o Whether object-oriented or traditional approaches, design starts where analysis
ends.
 Iterative and Concurrent Processes
o In iterative methodologies, analysis and design can happen in parallel.
o However, requirements (analysis) are usually clarified before solution planning
(design).
 Analysis Focus
o Decompose complex business processes and information needs into smaller,
manageable parts.
o Create models (e.g., use case diagrams, data flow diagrams) to understand and
communicate requirements.
o Heavy user involvement ensures correctness and completeness of these models.
 Design Focus
o Convert requirements models into solution-oriented models.
o Emphasizes technical concerns (less user involvement, more input from technical
experts).
o Results in diagrams and documents describing how the system will be built.
 Project Formality and Documentation
o Formal Projects: Require comprehensive design documents, regularly reviewed
in formal meetings.
o Informal Projects: Might rely on quick sketches or notes—sometimes discarded
once coding is complete.
 Even in Agile, essential design activities still occur, though less
documentation may be produced.
 Avoiding “Cowboy Coding”
o Jumping straight into coding without thorough design can lead to errors, patches,
and unstable systems.
o Even in agile or informal settings, proper design thinking is crucial to reliability
and maintainability.

Let’s break it down into simpler terms and explain step by step with examples to make it easier
to understand:
What Are Application Components?

 Definition:
o Think of an application component as a building block of a system.
o Each block has a specific job, like:
 A login system for a website.
 A feature to display search results.
 A method to process payments.

Why Are Components Important?

 Components help:
o Break down a large, complicated system into smaller, manageable pieces.
o Make the system easier to design, build, and maintain.
o Allow parts to be reused in other systems or projects (like a pre-built login
system).

Characteristics of Components

1. Size/Scope:
o A component can be:
 Small: A single method or function (e.g., a code snippet to calculate
taxes).
 Large: A subsystem with many parts (e.g., the shopping cart system in an
online store).

Example: In an e-commerce site:

o Small component: Code that calculates shipping costs.

o Large component: A system that manages customer orders.
2. Programming Languages:
o Components can be written in different programming languages, depending on
the need:
 Traditional languages like C define components as "functions" or
"procedures."
 Object-oriented languages like Java or C# use "classes" and "methods."
 Scripting languages like JavaScript or PHP embed components in web
pages.

Example:
 o A JavaScript component on a webpage validates a form (e.g., checks if the email
is valid before submitting).
3. Build or Buy:
o Not every component has to be built from scratch:
 Some can be reused from other systems.
 Others can be purchased (e.g., APIs like Google Maps or Stripe for
payments).

Example:

o Instead of building a map system, a company might use the Google Maps API as
a component in their app.

How Are Components Designed?

Designing application components involves:

1. Breaking the System into Subsystems:

o Divide the system into parts that handle specific tasks.
Example:
 Subsystems of a banking app:
 User login system.
 Account balance display.
 Fund transfer system.
2. Using Multilayer Design:
o A system is often split into three layers:
 User Interface: How users interact with the system (e.g., buttons, forms).
 Business Logic: The rules or logic behind the scenes (e.g., calculating
account balance).
 Database: Storing and managing data (e.g., account details).

Example:
For an online store:

oUser clicks "Add to Cart" → (UI Layer).

oSystem checks if the item is in stock → (Business Logic Layer).
oUpdates the cart data in the database → (Database Layer).
3. Making Components Fit the Technology:
o The tools and technologies used by the organization (e.g., .NET or Oracle) affect
how components are designed.

Example:
 o A company using Microsoft SQL Server and .NET would design components
differently than one using Oracle technologies.

What Happens After Designing Components?

 Once the application is divided into components:

o Each component is further detailed into smaller parts, like software classes and
methods.
o The result is a set of diagrams and documents that show how everything will
work.

Key Takeaways

1. Application components are the building blocks of a system, each performing specific
tasks.
2. Components can vary in size, language, and source (built in-house, reused, or
purchased).
3. Designing components involves breaking the system into subsystems and planning their
interaction.
4. Components are adapted to fit the organization’s technology and are organized into
layers (UI, business logic, database).

If you're still unsure about something specific, let me know, and we can go through an example
or clarify further!

Key Points on Designing the User Interface:

Importance of User Interface (UI)

1. "The UI is the System":

o To users, the interface represents the system. Their experience with the UI often
determines their perception of the entire system.
2. Impact on Success or Failure:
o Poor-quality interfaces can lead to system and business failure.
o High-quality interfaces improve user satisfaction, employee productivity, and overall
morale, and can become a competitive advantage.
o Bad interfaces result in errors, inefficiency, and frustration.
Evolving User Interface Requirements

1. Past Focus:
o Simpler times: Focus was on desktop computers, minimizing keystrokes and mouse
clicks.
2. Modern Demands:
o Must accommodate multiple devices (e.g., phones, tablets, desktops, large displays).
o Interfaces may need to support:
 Multitouch screens.
 Voice recognition.
 Eye-tracking cameras.
o Users now interact across different devices and contexts (e.g., desk, conference room,
while traveling).
o Designing one UI for all contexts is increasingly rare; UIs must now adapt to multiple
technologies and platforms.

User Interface Design Activities

1. Analysis Aspects:
o Understanding:
 User needs: What users expect and require from the system.
 User workflows: How users perform their tasks and interact with the system.
 Interaction contexts: The devices, locations, and physical environments where
the system will be used.
2. Design Aspects:
o Deciding how related software features are:
 Distributed across devices.
 Packaged into different components.
o Leveraging device capabilities (e.g., touchscreens, voice input).

Models and Examples (Figure 6-5):

1. Layers in UI Design:
o View Layer: User-facing elements (e.g., windows, forms, pages).
o Domain Layer: Business logic (e.g., cart handlers, account management).
o Data Access Layer: Database connections and data retrieval.
2. UI Technologies:
o Frontend Technologies: HTML, JavaScript, PHP, JSP, etc., for creating responsive
interfaces.
o Backend Integration: Interfaces interact with components like databases and
application servers.
3. Example: E-commerce system UI:
o View Layer: Login window, item search, cart display.
o Domain Layer: Business logic like cart management or promotional offers.
o Data Access Layer: Retrieving product details, customer data.
Key Takeaways

1. The UI defines user experience and can determine system success.

2. Modern UIs must adapt to a variety of devices and contexts.
3. UI design involves understanding user needs and workflows while leveraging device-specific
features.
4. UIs are part of a layered design, working with backend logic and databases.

By focusing on these principles, you can design user interfaces that are intuitive, efficient, and
effective for diverse user environments. Let me know if you'd like an example walkthrough or
further clarification!

Key Points on Designing the Database:

Role of the Database in a System

 The database is a core component of any information system, responsible for storing and
managing information.
 The data model (developed during analysis) forms the foundation for designing the database.

Key Design Decisions

1. Database Structure:
o Traditional Files: Simple collections of computer files.
o Relational Databases: Complex systems with dozens or hundreds of interconnected
tables.
o Hybrid Systems: Combination of files and relational databases.
2. Centralized vs. Distributed Databases:
o Centralized Database: All data is stored in a single location.
o Distributed Database: Data is spread across multiple locations, sometimes globally.
3. Internal Database Properties:
o Attribute types (e.g., string, integer).
o Default values for fields.
o Access controls (permissions for users or roles).
4. Integration with Existing Systems:
o Ensure compatibility and smooth integration with other databases.

Technical Considerations

1. Performance Optimization:
o Focus on response times and system speed.
 o Use performance tuning techniques during design.
2. Security and Encryption:
o Protect sensitive data through encryption and robust security mechanisms.
o Plan access restrictions and user authentication.
3. Global Connectivity:
o Address challenges of database replication and partitioning for systems operating in
multiple regions.
o Consider multiple database systems (DBMSs) operating across different servers and
sites.

Role of Database Experts

 Complex database systems often require input from specialists:

o Database Designers: For structure and configuration.
o Security Experts: For encryption and access control.
o Performance Experts: To ensure the system meets technical requirements.

Outputs of Database Design

 Implementation Models: Detailed specifications of tables, relationships, and data structures.

 Sample Table Definitions: For instance, a MySQL table for managing inventory items (e.g.,
defining columns like product name, stock quantity, etc.).

Key Points on Designing Software Classes and Methods:

Purpose of this Activity

 Transform analysis models (class diagrams, sequence diagrams, etc.) into blueprints for coding
software.
 Provide enough detail so that programmers can write, test, and deploy the software effectively.

Steps in Software Design

1. Extend Analysis Models:

o Incorporate software-specific details (e.g., methods, algorithms).
o Models include:
 Class Diagrams: Define the structure and relationships of software classes.
 Sequence Diagrams: Describe how methods interact over time.
  State-Machine Diagrams: Show how objects change states.
2. Create New Models:
o Add detailed diagrams for how the software components will interact.
3. Blueprint for Programming:
o These models act as the foundation for developers to write methods and implement
system functionality.

Key Outputs

 Design Class Diagrams:

o Detailed diagrams showing software classes, their attributes, methods, and
relationships (e.g., for an order management system).
 Sequence Diagrams:
o Illustrate the flow of messages between objects during a process.

Final Steps

 Once software methods are designed:

o They are programmed, tested, and packaged for deployment.
o These steps ensure that the software components work as intended and are ready for
use.

Summary:

 Database Design focuses on structuring and managing data efficiently, with decisions about
architecture, performance, security, and integration.
 Software Classes and Methods Design involves creating detailed blueprints for the coding
process, extending analysis models into implementable software components.

Let me know if you'd like further clarification or an example walkthrough!