Software Engineering

made by: Nada AlHomaid 2024-1446

.‫ كل شي هنا من الساليدات خاصة االمثله و الرسمات‬2024 ‫ملخص مرتب لمادة هندسه برمجيات جزئيه الفاينل‬

(2, 7, 8, 9, 10, 11, 12, 13, 14, 15, 17, 18, 19)

.‫دعواتكم لي بالتوفيق‬

ch2 intro
Topics:

1. Software Engineering activities

2. SE and the Web
3. Software as a Service (SaaS)
4. SE ethics

Software Engineering and Process Activities

Specification: Define the software and constraints.

Development: Design and implementation the software according to specifications.
Verification/Validation: Ensure customer needs are met.
Evolution: Modify and evolve based on market/customer requirements.

Software Engineering and the Web

Web-Based Systems:
Accessed via browsers, reducing the need for local installation.
Instant worldwide accessibility.
Advantages (developer perspective on web software):
Faster software delivery, cost reduction, and easy upgrades.
Encourages incremental development methods to deliver software.
Constraints:
Limited by browser capabilities.

Software as a Service (SaaS)

Software is delivered as a web service rather than locally installed.

ex: google docs and spreadsheets.
Platform (PaaS): provide cloud components and framework for software creation,
Eliminate concerns about OS, storage or infrastructure.
ex: google app engine.
Infrastructure (IaaS): Scalable resources like servers and storage, OS via virtual tech.
ex: VM ware.

Benefits: Pay-as-you-go model, accessible anywhere, and no need for expensive devices.

Drawbacks: Limited control, security concerns, internet dependence, performance issues.

Software Engineering Code of Ethics and Professional Practice (SEEPP)

A set of principles established by ACM/IEEE-CS to guide software engineers in ethical

conduct.
Software engineers are those who contribute either by direct participation or by:
teaching, certifying, analyzing, designing, developing, maintaining and testing
of software systems should follow the code.

Principles:

1. Public: Act in the public's interest (e.g., ensure safety and fairness).
2. Client and Employer: Serve clients ethically and protect confidentiality + public interest.
3. Product: Maintain professional standards for quality and testing of their product.
4. Judgment: Ensure integrity and independence in their professional judgment.
5. Management: Promote ethical practices in project management by managers/leaders.
6. Profession: Enhance the reputation and integrity of software engineering+public interest.
7. Colleagues: Support and encourage ethical behavior among colleagues.
 8. Self: Commit to lifelong learning and ethical growth.

Ethics in details (copy of the slide):

1. PUBLIC: Software engineers shall act consistently with the public interest.

Examples:

Accept full responsibility for their own work.

Moderate the interests of the software engineer, the employer, the client and the users
with the public good.
Approve software only if they believe that it is safe for use, meets specifications, passes
appropriate tests.
Disclose to appropriate persons or authorities any actual or potential danger to the user,
the public, or the environment.
Be fair and avoid deception in all statements, particularly public ones.
Consider issues of physical disabilities and allocation of resource.
Be encouraged to volunteer professional skills to good causes.

2. CLIENT AND EMPLOYER: Software engineers shall act in a manner that is in the best
interests of their client and employer, consistent with the public interest.

Examples:

provide service in their areas of competence.

Not knowingly use software that is obtained or retained either illegally or unethically.
Use the property of a client or employer only in ways properly authorized.
Identify, document, collect evidence and report to the client or the employer promptly if,
a project is likely to fail or to violate intellectual property law.
Ensure that any document upon which they rely has been approved, when required, by
someone authorized to approve it.
Keep private of confidential information gained in their professional work.

3. PRODUCT: Software engineers shall ensure that their products and related modifications
meet the highest professional standards possible.

Examples:

Strive for high quality and acceptable cost.

Ensure proper and achievable goals and objectives for any project.
Ensure that they are qualified for any project they work on.
Ensure that an appropriate method is used for any project.
Work to follow professional standards.
Strive to fully understand the specifications for software.
Ensure adequate testing, debugging, documentation and review of software.

4. JUDGMENT: Software engineers shall maintain integrity and independence in their

professional judgment.

Examples:

Temper all technical judgments by the need to support and maintain human values.
Only endorse documents if prepared under supervision.
Maintain professional objectivity with respect to any software.
Not engage in deceptive financial practices such as bribery, double billing, or other
improper financial practices.
Disclose to all concerned parties those conflicts of interest that cannot reasonably be
avoided or escaped.

5. MANAGEMENT: Software engineering managers and leaders shall subscribe to and

promote an ethical approach to the management of software development and maintenance.

Examples:

Ensure good management for any project on which they work.

Ensure that software engineers are informed of standards before being held to them.
 Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and
outcomes on any project.
Provide for due process in hearing charges of violation of an employer's policy or of this
Code.
Not ask a software engineer to do anything inconsistent with this Code.

6. PROFESSION: Software engineers shall advance the integrity and reputation of the

profession consistent with the public interest.

Examples:

Help develop an organizational environment favorable to acting ethically.

Promote public knowledge of software engineering.
Support, as members of a profession, other software engineers striving to follow this
Code.
Not promote their own interest at the expense of the profession, client or employer.
Take responsibility for detecting, correcting, and reporting errors in software.
Report significant violations of this Code to appropriate authorities.

7. COLLEAGUES: Software engineers shall be fair to and supportive of their colleagues.

Examples:

Encourage colleagues to adhere to this Code.

Assist colleagues in professional development.
Credit fully the work of others and refrain from taking undue credit.
Assist colleagues in being fully aware of current standard work practices.
Not unfairly intervene in the career of any colleague.

8. SELF: Software engineers shall participate in lifelong learning regarding the practice of
their profession and shall promote an ethical approach to the practice of the profession.

Examples:

Further their knowledge of recent developments.

Improve their ability to create safe, reliable, and useful quality software.
Improve their ability to produce accurate, informative, and well-written documentation.
Improve their knowledge of relevant standards.
Not influence others to undertake any action that involves a breach of this Code.
ch7 Software Requirements
Software Requirements Overview:

Need for Software: Software is required if it is essential or economically justified.

Definition: Software requirements specify what is needed or wanted from the software.
Range: Requirements can range from abstract statements to precise mathematical
functions.

Types of Requirements:

1. User Requirements “‫” يعني هو يقول وحنا نسجل الي يبي‬

High-level, abstract, written in natural language or diagrams.
Define the system’s services and conditions.
2. System Requirements
Detailed descriptions of system functions, services, and constraints.
Software Requirements Specification (SRS) must document user/system
requirements.
SRS describes what is to be developed (design and implemented).

Requirements types and people involved:

Requirements should be written at different level of details because people who are
interested in reading them have different background (e.g. users, developers).
User requirements: Focus on what the system should do, not how.
System requirements: Want to know exactly what the system will do.
How it will support business processes
Or they are involved in the system development/implementation

Classification of Requirements:

1. Functional Requirements
Define services and functions the system provides.
May include constraints like what the system must or must not do.
it can be:
Vague, unreasonable, contradictory, simply impossible.
Clients may not present what they want technically.
SW engineers need meetings to understand what clients want/need.
Requirements at least need to be complete and consistent when documented.
2. Non-Functional Requirements
Define overall system properties and constraints (all functions ).
Important: The system may not operate if they are absent.
including:
Product Requirements: Specify the constraints on system behaviours.
e.g., timing, efficiency, performance.
Organizational Requirements: Policies, development practices.
External Requirements: Standards, legal, ethical considerations.
the standards they oppose on us.

Metrics for Non-Functional Requirements:

Speed “efficiency ”: Transactions processed, responsiveness of system, refresh time.

Size “space/efficiency ”: Storage capacity.
Ease of Use “usability”: Training time, interface design.
Reliability “dependability ”: Mean time to failure, number of failures.
Robustness “dependability / ‫”متانه النظام‬: Restart time after failure, % of data loss on fail.
Portability “usability”: Compatibility with multiple systems, number of target systems.

Example on functional / non functional requirements : “chat GPT ‫” حل‬

a university public computer Public access computers are located across university
campuses, and they have access to the internet. The computer should allow users to access
these computers and provide a decent and acceptable internet connection. Each user is
allowed to access the computer for 10 minutes from the start of the session. At the end of
the session, the user is allowed to renew the session for another 10 minutes or exit. Access
renewals should only be allowed three times in a row. The content to which the user can
access should not violate regulations put forward by the government.
 functional:
a. The computer should allow users to access the internet.
b. Each user is allowed 10 minutes of access per session.
c. Users can renew their session for another 10 minutes.
d. Access renewals are limited to three consecutive times.
e. The content accessed by users must not violate government regulations.
non-functional:
a. The internet connection should be decent and acceptable.
b. The system must comply with government regulations regarding content access.
c.

Software Requirements Specification (SRS) Documentation: “‫”الملف الي فيه الريكوايرمنت‬

Purpose: To document user and system requirements in detail, including (non/fun req).
methods of writing:
1. Natural language.
2. Structured Natural language (preferred).
3. Design description language. (e.g. using programming language )
4. Graphical notations: using models to define functional requirements. (e.g., UML).
5. Mathematical specifications.
Standard Format:
Description, Rationale statement, inputs, outputs, actions, pre-conditions, and post-
conditions.
notes:
use highlight for keyword or important sentences.
Use shall for mandatory
Use should for desirable
clarity when documenting.

SRS Outline:

1. Introduction: Purpose, scope, references, structure.

2. System Overview: Features, user roles, environment, constraints.
3. Requirements Engineering: Elicitation, analysis, validation.
4. Functional Requirements: Detailed list.
5. Non-Functional Requirements: Performance, security, quality.
6. External Interface Requirements: User, hardware, software, communication.

Requirements Management:

Need for Change: Requirements evolve due to business/technical changes, budget

constraints, or new regulations.
Tools for Management:
1. Requirement Storage: Centralized, secure repository for all requirements.
2. Change Management: Problem identification, analysis, cost estimation,
implementation.
3. Traceability Management: Track how changes affect related requirements.
ch8 Requirement Engineering
Requirements Engineering Process

1. Requirements elicitation: Discover what services the system should provide.

2. Requirements analysis and specification: Organize, prioritize, and document
requirements.
3. Requirements validation: Ensure requirements meet customer needs.

Feasibility Study and What Lies Ahead

A feasibility study is a concise, focused analysis conducted early in the Requirements

Engineering (RE) process to evaluate the project's viability.

Key Questions:

1. Does the system contribute to the organization's objectives and is it economically

justifiable?
2. Can the system be implemented within the schedule and budget using current
technology?
3. Can the system be integrated with other existing systems?

Outcome: If the answer to any of these questions is "no," it is advisable not to proceed with
the project.

Requirements Elicitation and Analysis

Technical staff works with clients to find services that the system should provide. The stages
include:

1. Requirement discovery: Interacting with stakeholders through interviews, scenarios, and

use cases.
2. Requirement Classification and organization: Grouping related requirements.
3. Requirement Prioritization and negotiation: Resolving conflicts and ranking importance
of the requirements.
4. Requirement Specification: Documenting requirements and input into the next round.

Challenges in Collecting and Understanding Requirements

1. Unclear Needs:
Stakeholders often provide only general ideas about what they want.
2. Personal Terminology:
Requirements are expressed in terms that reflect the stakeholders' knowledge and
experience.
3. Varied Perspectives:
Different stakeholders have unique and sometimes conflicting requirements.
Engineers must identify all requirement sources, resolve conflicts, and find
commonalities.
4. Political Influences:
Managers may push for specific requirements to increase their influence within the
organization.
5. Dynamic Environment:
Economic and business changes can lead to new requirements.
Additional stakeholders, not initially involved, may introduce new needs.

Techniques for Requirements Discovery:

1.Interviewing Stakeholders

Approach: Conduct formal or informal interviews to understand the system's

functionalities.
Types:
Closed Interviews: Predefined questions guide the conversation.
Open Interviews: Flexible discussions to explore issues in depth.
Effective Interviewing Tips:
Be open-minded, avoid biases, and actively listen.
Encourage stakeholders to provide contextual insights.

2.Scenarios
 Definition: Simulated real-life interactions that describe how the system will be used.
Components:
Expectations at the start of the scenario.
Normal flow of events.
Possible issues or deviations.
Related activities and final system state after completion.

3.Use Cases

Definition: A use case is a method for capturing the functional requirements of a system
through textual or graphical representations of interactions, describing the typical
interactions between actors (users or external systems) and the system using UML diagrams.

Key Characteristics

Captures Functional Requirements: Helps define what the system should do.
Challenges:
Clients may not fully understand or articulate what they need.
Developers may lack context or detailed understanding of system requirements.
Narrative Format: Provides a clear narrative of how the system is used, including:
The basic flow of events in a use case.
Variations or alternative paths where exceptions occur.
System Design Utility: Useful for:
Designing user interfaces.
Clarifying user goals and expectations.

Components of a Use Case

Actors: The entities (users or systems) interacting with the system.

Actions: The set of steps defining the interaction between actors and the system.

UML Graphical Use Case

Diagram Elements:
Actors: Represented as stick figures or labeled entities.
Use Cases: Represented as ovals, showing the actions or functions.
Relationships: Use arrows or lines to depict associations, dependencies, or extensions
, include, generalization, between actors and use cases.
System Boundary: Defines the scope of the system within the diagram.

Example on use case:

A customer accesses a list of bank services via an ATM connected to a bank. The services
provided are checking balance, withdrawing cash, paying bills, etc. Doing the operation must
be approved by the bank. The ATM handles authentication processes according to bank
authentication. There is a person that must observe any transaction (observer).
4.Ethnography

Approach: Observational studies in the operational environment to identify implicit or

overlooked requirements.
Definition: A study of the social and organizational context of operational processes to
uncover details overlooked by other methods.
Purpose:
Helps identify missing or implicit requirements.
Requirement analyst gets deeply into the working environment.
Reveals how defined processes interact with actual work practices, which may be
more dynamic than originally defined.

Scenario and Use Case Guidelines

1. Define Scope: Clearly outline system boundaries.

2. Identify Actors: List all users or systems interacting with the system.
3. List Goals: Brainstorm user objectives “goals for system”.
4. Outline Summary Use Cases: Highlight high-level use cases.
5. Refine Use Cases: Adjust goals by adding, removing, or merging.
6. Check Events: Include time-based triggers and boundary events.
7. List Extensions: Note variations and exceptions.
8. Write Main Success Scenario (MSS): considering the use cases.
9. Write alternative scenarios of main scenario.

Requirements Validation

Ensures the system meets customer expectations. Types of checks:

1. Validity: Satisfying all stakeholder needs.

2. Consistency: Resolving conflicting requirements.
3. Completeness: Including all necessary functionalities and constraints.
4. Realism: Ensuring implementability.
5. Verifiability: requirements should be written so that they are verifiable (allow a set of
tests to be written) .

Validation Techniques:

1. Requirements reviews: Systematic error checks.

2. Prototyping: Temporary system versions for feedback.
3. Test-case generation:
Purpose: Create tests based on requirements to identify errors.
If a test is difficult to create, the requirement may be hard to implement or verify.
Agile Approach: In agile programming, engineers develop tests from user
requirements before coding begins.
ch9 Software Architecture I
Software Architecture Overview

Describes major system components, their communication, and data exchange.

Ideally developed early, between requirement specification and system design.

Levels of Architecture:

1. Internal Architecture: Focuses on decomposing a program into components.

2. External Architecture: Manages architecture for complex systems distributed over
multiple locations of maybe beyond geographical boundary.

Why Software Architecture Matters

1. Stakeholder Communication: Facilitates discussions about internal and external

components.
2. System Analysis: Ensures non-functional requirements (performance, security) are met.
3. Large-scale reuse: for systems with similarities, software architecture can tell
whether reuse is possible.

Software architecture, symbols:

Rectangle box shape to represent components.

Rectangle shape block contains a number of boxes to represent subcomponents.
Arrow lines to represent data flows or signals between components.
draw back of symbols:
Lack of semantics (E.g. arrows don’t show relationships between entities).
Very abstract.

Architectural Design and Non-Functional Requirements

Performance: Minimize communication by localizing critical operations.

Security: Use layered structures with critical assets in inner layers.
Safety: Centralize safety-related operations to reduce validation costs.
Availability: Include redundant components in architecture design so that it is possible
to update/replace component without stopping the system.
Maintainability: Use self-contained, fine-grained components for easier updates.

Architectural Patterns

1. Model-View-Controller (MVC): Common in web development (e.g., Django, ASP.NET).

2. Layered Architecture: Used in SaaS and service-oriented applications.
3. Repository Architecture:Describes how system components share data .
e.g., DBMS, compilers.
a. Shared data: a central database that may be accessed by all components
b. Self-contained database that is only accessed by the contained component.
4. Client-Server Architecture:Mostly used for general access to static content on servers.
EX: email servers, Git.
5. Pipe and Filter Architecture: used for applications that have chain execution
This architecture can be used for applications that are developed using component-
based (reuse-oriented) development model.
The output of one component can be filtered/transformed or selected to be input for
the next component.
6. Service-oriented architecture (SOA). “explained in software architecture II below”

Examples of Software Architecture

An authentication tool is required to allow students of a university to access, via web-

browsers, a cloud application. A student needs to submit his/her student credentials to the
tool for access. The tool then checks the credentials with the university with pre-defined
interface. If authenticated, the student is allowed to access the cloud application.
 Clients wish to have a system that helps them to manage their online shop. The shop allow
visitors to explore online list of items or search for particular items. On selection of an item,
the visitors can specify the desire quantity and add them to the shopping cart. On checkout,
the visitor can specify shipping address and payment details (or load if registered customer).
Once approved transaction of payment with the bank, the details of the shipments are sent
to the target retailers of the items.

Draw a software architectural design that shows the main components of the given
description above.
ch10 Software Architecture II
Service-Oriented Architecture (SOA):

Develops distributed systems where components are web services.

Commonly used in SaaS applications, with services executed across geographically
distributed systems.

SOA Lifecycle:

1. Analysis:
Define stakeholder requirements (new systems) or functionality and infrastructure
(existing systems).
Identify scope of service, likely clients, performance, and availability.
Determine candidate service operations and relevant data structures.
identify candidates input, output, potential faults (informally).
2. Design:
Refine candidates into formal service operations following principles:
Statelessness: Independent transactions for each request.
Abstraction: Hide implementation details from client.
Reusability/Composability: Organize and reuse behavior across operations.
3. Development.
4. Testing:
Assess performance under:
normal conditions: good service performance.
peak conditions: acceptable service performance.
overload conditions: services remains operational (do not crash).
Evaluate performance:
response time.
throughput (e.g. requests per second).
resource usage (CPU, memory).
5. Deployment:
Identify issues not seen in standalone systems.
Distribution and replication of services.
E.g. Fail-over, load balancing behaviour.
Co-existence of multiple versions of the same service.
E.g support clients who have different version that the latest interface.
Run performance tests on deployed services Handle distribution, replication, and
multiple service versions.
6. Administration:
Monitor performance.
dynamically allocate resources.
detect bottlenecks: the capacity of the system under monitoring is limited to a lowest
throughput possible.

Heterogeneity and Distribution

Applications differ in:

Implementation languages, storage formats, OS, and hardware.
Distributed across machines or physical locations but must interoperate.

Communication/Integration scenario:

Service A and B can communicate.

Service A wants to resolve postcodes and therefore communicate with Service B.
Service B takes any postcode given by Service A and creates entries of addresses and
makes it available to Service A.
Service A reads the information put by Service B and use it.

Primitive Integration Patterns: Describes the ways of communication and information

exchange between systems.

1. File-Based Communication:
Data exchanged via files (e.g., postcodes.text).
Issues:
Lag “not real-time”.
file locking: Only one action is allowed in a file.
client scaling challenges
 ad-hoc file formats: A and B must agree upon a file format to use.
Housekeeping: clean (big / not needed/ corrupted) files.
2. Common Database:
Shared database allows synchronization and access by multiple clients, Ad-hoc file
format.
Requires housekeeping for maintenance.
3. Sockets:
Enables real-time communication via unique IP and port numbers.
Both client and provider can read/write through sockets.

Data Exchange Formats

Serialization: is a set of rules that defines how bytes/characters should be interpreted.

The set of rules of serialization and parsing must be known by all parties.
Challenges: Writing parsers/serializers from scratch is time-consuming and error-prone,
low- level.
Any changes to B’s parsing, must be addressed in A’s serializer.

XML (eXtensible Markup Language)

Features:
Support for different structured data, platform/machine-independent, machine-
readable, text-based format.
Extensible for various applications.
ch11 Software Design I
System Modeling

Purpose: Create models of a system or subsystems to clarify functionality, identify

strengths and weaknesses, and assist in system design or documentation.
created using: UML graphical notation.
Uses:
Existing systems: Clarify functionality (strength/weakness).
New systems: Aid in requirement explanation, design, and documentation.
Model-driven engineering: Enable partial or full implementation of target systems.
Perspectives “which models are created”:
1. Context/Environment: Define system boundaries and external systems.
2. Interaction: modeling interactions between system components and the whole
system with surrounding environment.
3. Structural: Model system organization and internal components and data structure of
the system.
4. Behavioral: model system activity and its response to events.

Unified Modeling Language (UML)

Definition: A standard graphical notation with 13 diagram types for modeling software
systems.
Common Diagram Types: (‫)االنواع الي بتجي باالختبار‬
1. Activity Diagrams: Model activities in a processes or data flows.
2. Use Case Diagrams: model interactions between a system and its environment. Used
for requirements.
3. Sequence Diagrams: model interactions between a system and its environment. Used
for requirements.
4. Class Diagrams: Represent object classes, properties, and relationships between them
in the system..
5. State Diagrams: Show system reactions to events (internal/external).

Context model:

Model system boundaries and external systems.

Identify what are the inputs provided by surrounding systems (environment).
After boundaries are known, a simplicaited architectural model is created.
Sometimes are used with other type of models such as process models or activity
models.

Interaction models:

Describe how group of objectives and components collaborate in some behavior.

Interactions:
User interaction: inputs outputs.
Component or systems interaction.
Modeling interaction of the system reveals communication problems between
components, Good for identifying problems in requirements.
Help to understand the proposed system.
ex: use case modeling , Sequence Diagrams.

Sequence Diagrams

Purpose: Illustrate behavior for specific scenarios with time-based object interactions.
Structure:
X-Axis: Objects or actors.
Y-Axis: Time sequence “time frame”.
Arrows show messages, processes, and responses.
Sequence Diagram Guidelines

1. Identify scenarios and related use cases.

2. List interactive objects (users, systems, components, computers).
3. Describe successful and alternative flows “Steps of scenario with interactive objects”.
4. Identify the calling and responsive flow with objects.

Example of Sequence Diagram:

In the city library, a student can search and pick a book then go to the self-service loaning
machine, which is connected to students’ records. The student must pass the book QR code
over the scanner of the machine. If the student has exceeded 3 books loans, then the system
refuses the request. Otherwise, the book is lent to the student, and the library tracker is
updated with the loaning information (student and book).
ch12 Software Design II
Behavior Models

Purpose: Describe how systems dynamically respond to:

Data: Incoming data that requires processing.
Events: Triggered actions the system must process.

Data-Driven Modeling

Models the sequence of actions for processing data and generating output “info/ data”.
Key Tools:
Data-Flow Diagrams (DFDs): Represent system processes and their data flows.
Activity Diagrams: Show the control flow between activities.

Data-Flow Diagram (DFD)

level 0: Visualize high-level system processes and their interactions with data stores and
external entities.
all external entities must be visible at level 0
Decomposition: Break processes into smaller sub-processes while maintaining integrity
(e.g., consistent inputs/outputs).
The numbering of process must follow parent model
EX: if process 3.2 decomposed, sub process ,use be 3.2.1 , 3.2.2 , ....
levels: context diagram, level 0, level 1, ...

DFD symbols:

Process: a unique name (verb phase), a number and a description for a process.
Data flow, data store, and external entity: a unique name and a description for it.

DFD Rules:

1. Every process must have at least one input and output.

2. Direct data flows between data stores or entities “external” are not allowed—they must
go through processes.
3. Bidirectional data flow is disallowed between symbols.
4. Cycled data flow is allowed. It must go through another process.
5. Maintain balanced diagrams across levels.

Example of DFD:

Autonomous taxi car is hired by travelers within strictly predefined zones within the city.
Upon hiring, users must provide credentials of all passengers for security check with
database, a single destination address, and payment information. The taxi has limited
availability.
Activity Diagrams

Purpose: Describe processes of systems and its subsystems, Show workflows and control
flows between system activities.
Components:
Nodes: Represent activities (can be composite or elementary actions).
Edges: Represent control flow.
Branching: Conditional paths based on decisions.
Forking/Joining: Synchronize concurrent activities.
Swimlanes: Organize activities by actor or role.
Rules:
has only one income and one outcome arc/edge.
may be composite and it can be further decomposed into sub-activities.
may be elementary and it is referred to as actions.

Activity Diagram Concepts

1. Branching
Simple Flow: The completion of one activity directly starts the next.
Branching Flow: Conditional logic determines which activity is executed next.
2. Forking and Joining
Synchronizes the start or end of activities with others.
Example: Certain tasks in a project cannot begin until others are completed.
3. Swimlanes
Organize activities by actors or roles involved in the process.
Useful for visualizing responsibilities and interactions.

Examples of Activity Diagrams:

Context: an oven microwave heats or defrost items while its door is closed and the start
button is pressed. A user needs to select/choose desire type and duration of service. Based
on the selection the microwave starts working and displays a countdown on the screen. Draw
an activity diagram that describes the activity above in one perspective: user.
ch13 Software Design “behavioral modeling”
Event-Driven Models

Definition: Illustrate how systems and components respond to internal or external

triggered events.
Key Features:
Systems have finite states, transitioning between them based on events.
Appropriate for real-time systems.
State transitions depend on specific conditions or the completion of other states.

Modeling Tools:

1. UML State/State Machine Diagrams.

2. Mathematical Models (e.g., Petri nets, finite-state automata).
3. Simulation Tools (e.g., Prism).

State Diagrams

Purpose: Describe an object’s lifecycle by detailing states and transitions.

Components:
State: A condition of the object at a specific point in its lifecycle.
Used in early stages of development to know the lifecycle of an object.
Transition: An event-driven action leading from one state to another, optionally
guarded by conditions.
An event is an occurrence that triggers a transition.

Actions in State Diagrams:

1. Transitions: Triggered by events and actions.

2. States: Using composite states use three actions:
Entry: action to do on entry of the state.
Do: action(s) after entry and while in state.
Exit: action to do on leaving the state.
A single state use only one action (decomposition).

Nested states: Modeled using composite state.

Guidelines for Design:

1. Brainstorm all possible states.

2. Determine what are the single states and what are the composite states.
3. Analyse the events/actions for transitioning from one state to another.
4. Associate the necessary conditions/constraints for the events/actions.

Examples of State Diagrams

Provide a state diagram that models a centralized air system according to the following
actions:

Fan model: triggered whenever the user presses the turn on while the system is in
standby mode or called by Cooling and Heating modes
Cooling mode: starts when the room temperature is above the room temperature set up
by customer. Once the temperature reaches or goes below the user temperature the
system goes to fan mode.
Heating mode: starts when the room temperature is less than the user temperature.
Once the temperature reaches or goes above the user temperature the system goes to
fan mode.
Standby mode: initial state of the system, triggered whenever the user presses the turn
off button from any state.
ch14 Software Design “Structural Modeling”
Structural Modeling

Definition: Represents system components (classes, entities), their properties

(attributes, operations), and relationships.
Structural models are helpful when designing the architecture of the system.
Types:
1. Static Models: Show system structure “entities” and relationships.
2. Dynamic Models: Represent components of system during execution.

UML Structural Models:

1. Class Diagrams:
Represent entities (classes), their properties, and relationships.
Classes are fundamental to object-oriented languages and programs.
they capture the abstract structure of the classes in the system.
they capture the relationships/associations between the classes.
Components “entities” (‫)فيه رسمه توضيحيه تحت‬:
Attributes: Define data types (e.g., Integer, Boolean).
Operations: Define functions with parameters and return types.
Relationships: Associations, aggregations, compositions, dependencies, and
generalizations.
Key Features “properties”:
Visibility: + public, - private, # protected.
Non-instantiatable classes:
Abstract Classes: Inherited by other classes, can implement operations.
Interfaces: Provide prototypes for operations only,(can not be gerelized
“inherit”, but can realized “implemented”).
Stereotype of class:
<<interface>> , <<abstract>> , before/above the name of class.
A class can generalize a class or abstract class. But, it can realize an interface.
If a class has a superclass or implements an interface, then:
graphical representation must illustrate that, or textually representation is used
inside of the class.
2. Object Diagrams:
Used to illustrate specific instances of a class diagram during execution.
Object names are underlined, and unnamed instances must have a type.

UML Relationships

UML Generalization:
Definition: Represents inheritance relationships.
Superclass: Parent class.
Subclass: Child class or specifications.
UML allows multiple inheritance (a class can inherit from multiple parents).
represented by: solid line with a hollow triangle.

UML Association:
Definition: Represents a bidirectional relationship between classes.
Multiplicity:
Defines the number of objects participating in the relationship.
Properties in Association:
Associations can have attributes or operations, represented as association classes.
Transformation:
An association class can be converted into an independent class with two
relationships.
Represented by:
Bidirectional: No arrowheads on either side.

UML Association Extensions

a. Aggregation:
Indicates one class is a component of another, but not strongly dependent.
represented by: solid line with a hollow diamond.
b. Composition:
Similar to aggregation, but the classes are strongly dependent.
represented by: solid line with a filled diamond.
 c. Dependency:
Shows that one object’s content depends on another.
represented by: dashed line with an arrowhead.
d. Navigation Association “Unidirectional”:
Describes a unidirectional relationship between two classes.
represented by: solid line with an arrowhead pointing toward the target class.

Class Diagram Components:

Example of Class Diagrams:

Create a class diagram that describes the structure of a store (with name and address)
that contains INF but at least one item (with details name, information, and price). The
store also contains INF order with basic details like list of items and their quantities.
Items can be categorized into three types: appliance, device, and cloth.
All attributes must all be specified as private attributes

Operations (all operations must be public):

Store: getName() that returns type string, updateAddress(), that accepts a new
address as string.
Item: getInfo() that returns type string, getPrice() that return real type.
Order: addItem() that accepts a new Item and returns a List type of item, getTotal()
that returns type real.
ch15 Model-Driven Engineering (MDE)
What is Model-Driven Engineering?

An approach to software engineering where models are main artifacts.

Models are used for processes like modeling, code generation, testing, evolution, and
reverse engineering.

Benefits of MDE: Models are easy to be manipulated and transformed and therefore enable:

1. Simplifies Complex Systems: Models provide abstract representations without

implementation details.
2. Understandability:easy to be understood by clients and people involved and
requirements checking.
3. Increase Productivity:with transformation, code correspond to system can be generated.
4. More Reliability: Automated transformations reduce errors/problems.
5. Interoperability: Standards like UML and MOF ensure compatibility across systems.

MDE Concepts:

1. Purpose of Modeling Languages:

Represent real objects (e.g., Book, Car, Animal).
Ensure models are:
1. Manageable and processable.
2. Validated and verified:
3. Model transformation.
2. Model Layers:
M1: Models (e.g., Book, Car).
M2: Metamodels (schemas defining models).
M3: Meta-metamodels (e.g., MOF).
3. Modeling Languages: Define syntax and concepts for creating models.
Examples:
UML: General-purpose modeling.
BPMN (Business Process Model and Notation): Business process modeling.
ex: Like activity diagram but more tailored to business processes.
Ecore: implementation of EMOF that UML conforms to.
4. Serialization: Models are stored using XMI (XML Metadata Interchange) for easy
processing.

Models are transformed from independent model to specific models that works
underline systems.

MDE Tasks

1. Model Transformation: “main task”

Converts one or several source models into other models.

Examples:
Transform a classical car model into an autonomous car model with more features and
safety constraints.
Migrate an old model to a new system with updated infrastructure and architecture.
Process:
Query source models to gather necessary information (mapping) to generate target.
Use metamodels of both source and target for navigation and object creation in
output models.

1.1. Model-to-Text Transformation:

Models are universal and they are system-independent.

Model2text takes a model as an input and create code of system language.
Examples:
 Generate a program to manage books in a database (create/update/delete).
Supports multiple target systems (e.g., PHP with SQL, Django with SQL).

1.2. Text-to-Model Transformation:

Converts textual input into models using static analyzers or parsers.

Examples:
Parse weather data text to generate graphical representations.

2. Model Validation:

A model must conform to its metamodel (schema) and its constraints.

important to check models from time to time if they are still valid according to its
constraints.
Examples:
A book must have a name and at least 10 pages.
A car must meet local government standards defined in the metamodel.

3. Model Comparison:

Compares models to identify differences or missing data.

Models are manipulated by management tasks, It is a requirement to check if the out
models are generated with no errors.
Any data can be changed according to three actions:
1. Add
2. Delete
3. Replace
Uses:
For merging models.
Example: Checking what data is missing from one model and amending it with another.

4. Metamodel creation:

A model must conform to its metamodel (schema).

Creation Methods:
Graphical: Similar to creating class diagrams in UML.
Textual: Easier for automation and integration with tools.
Reverse Engineering: Auto tools can produce other artifacts from metamodels.
Constraints and Invariants:
Any model generated from the metamodel must be valid after that
Example: All medical staff must have licenses issued or renewed within the last year.

5. Model Generation:

Converts a metamodel (domain model) into an object model (instances of the

metamodel).
Again it can be done:
Graphically: Time-consuming and less flexible.
Textually: Enables automation and propagates changes easily.
Model generators can be written in general-purpose languages (e.g., Java, C++) or
dedicated languages (e.g., Epsilon).
ch17 Software Implementation II
Common Code Smells and Their Solutions:

1. Duplicated Code
Issue: The same code appears in multiple places.
Solution: Use Extract Method and invoke the method where needed.
2. Long Method
Issue: Difficult to understand and maintain.
Solution: Use Extract Method to simplify and distribute responsibility.
3. Large Class
Issue: A class is handling too many responsibilities or has many variables.
Solution:
Use Extract Class or Extract Subclass.
Remove duplication using Extract Method.
4. Long Parameter List
Issue: Hard to understand and manage.
Solution:
Replace parameters with methods.
Use Introduce Parameter Object.
5. Divergent Change
Issue: A class changes in multiple ways for different reasons.
Solution: Identify related changes and group them using Extract Class.
6. Data Clumps
Issue: Data groups repeatedly appear together in multiple places.
Solution:
Use Extract Class to group them into an object.
Use Introduce Parameter Object to simplify method signatures.
7. Switch Statements
Issue: Duplication and difficulty maintaining multiple switches.
Solution:
Use Extract Method for the switch statement.
Use Move Method with polymorphism when needed.
8. Comments
Issue: Excessive comments may indicate poorly written code.
Solution:
If explaining a block of code, use Extract Method.
If a method still needs a comment, use Rename Method for clarity.
Use comments to explain why something was done, not what.
ch18 Software Testing I
What is Software Testing?

Testing involves executing a program against input data to reveal hidden errors and ensure
correctness.

Goals:

Test all program features and contributing processes.

Discover incorrect, undesirable, or non-conforming behaviors.
Detect defects like system crashes, unwanted interactions, incorrect computations, or
data corruption.

Aim of testing: is to establish confidence that the system is ‘fit for purpose

Software purpose: the level of confidence depends on how critical the software is to an
organisation.
User expectations: Users may have low expectations of certain kinds of software.
Marketing environment: getting a product to market early may be more important than
finding defects in the program

Verification vs. Validation

1. Verification (Building the product right):

Detects bugs and errors.
Uses oracles to check expected outputs.
2. Validation (Building the right product):
Confirms the product meets user requirements.
Prototyping helps clarify feature behavior.

Software Verification

1. Static Verification (Inspections):

Analyze system artifacts (e.g., requirements, models) without execution.
Use tools and domain knowledge to detect errors.
2. Dynamic Verification (Testing):
Execute the system with test data.
Observe behavior to identify errors.
‫فيه رسمات “توضيحيه” بالشابتر‬

Development Tests Levels:

1. Unit Testing (class - method level): ch19

Tests individual methods or object classes.
Focus: Object and method functionality.
2. Component Testing (package level):
Tests integrated units as composite components.
Focus: Interface behavior.
3. System Testing (all packages):
Tests the entire system as a whole.
Focus: component Interactions.

Testing Strategies

1. Partition testing into packages, processes methods, folders, and classes.

2. Choose inputs to:
Generate errors.
Cause buffer overflows.
Produce invalid outputs.
Test extreme computational results.

1. Automated Testing

Unit testing should be automated “ without manual intervention”.

Unit testing frameworks provide generic test classes that you extend to create specific
test cases.
tools like JUnit or cppunit.
Components “parts”:
1. Setup: Initialize the system with test cases.
 2. Call: call the object or method to be tested.
3. Assertion: Compare actual results with expected outputs.

2.Component Testing:

Focuses on testing interacting objects (classes, methods, variables) within a component.

Ensures that interfaces between components function as specified.
Guidelines
a. Test parameters at extreme ranges.
b. Test pointer parameters with null values.
c. Design tests to force failures.
d. In shared memory systems, vary activation order of components.

3.System Testing

Purpose: Integrate components to create a version of the system and then testing the
integrated system.
Focus:
1. Test interactions between components.
2. Verify compatibility and correct data transfer across interfaces.
3. Assess emergent behavior of the system.

Specialized Testing

1. Release Testing:
Ensures the system is ready for external use.
Focus: Functionality, performance, dependability.
Black-box testing derived from specifications.
2. Regression Testing:
Ensures updates don’t break existing functionality.
it requires automated testing.
test must run successfully before committing any change.
3. Test-Driven Development (TDD) “‫”فيه رسمه توضيحيه‬:
An approach to software development in which you interleave (merge) testing and
code development.
Write tests before code.
tests and code are developed incrementally
You don’t move to next increment until the code passes its pre-developed tests.
TDD is essential element in agile methodologies, can be in plan-driven development.
Benefits:
Full code coverage: every code written will have at least one test.
Incremental regression test suite.
Simplified debugging: when a test fail; easy to know where the problem.
Tests double as documentation: describe what the code should be doing.

User Testing:

Purpose: Involve users/customers in testing to gather input and feedback/advice.

Importance: Essential even after system and release testing.
The reason for it; user’s working environment have a major effect on the:
Reliability, Performance, Usability, Robustness “‫ ”متانه النظام‬of the system.
Types:
a. Alpha Testing: Early testing of software by clients and developers.
b. Beta Testing: Experimental releases of software for user feedback.
c. Acceptance Testing: Clients test the system to decide if it is ready and be accepted.
ch19 Unit Testing
A fundamental practice to verify the correctness of individual software components.

Unit Testing Approaches:

1. Black-Box Testing:
developers do not necessary know about implementation details to do the testing.
Example: Testing a reused component.
2. White-Box Testing:
developers have access to the code and able to track the execution of a test.
Example: testing to compute code coverage.
3. Grey-Box Testing:
developers have partial access to the code and able to track part of the execution of a
test.

Unit Testing Techniques:

1. Specification-Based Testing:
Tests software against its specifications.
Advantages: Systematic, simpler than implementation.
Drawbacks: Not all specification (like informal ones) can be converted to tests.

2. Model-Based Testing:
Uses behavioral models to generate test cases that can be used to find discrepancies
“‫ ”التناقضات‬between actual program behaviour and the model.

3. Random Testing (Fuzz Testing):

Generates random inputs to find crashes or anomalies.
Goal: could this result possible to be right?
Advantage: it ignores the knowledge about how the program works.
includes search-based testing.

4. Boundary Testing:
Testing by choosing inputs that are on semantically-significant (extreme) boundaries
(ends).
Boundary values for: Boolean, Character, Numeric (integer, float, double, ... ), String.

5. Coverage-Based Testing: *
Goal: Achieve pre-agreed coverage levels for class, methods, statements, and paths.
Types:
Statement Coverage: Ensures each statement executes at least once.
Branch Coverage: Tests all decision branches at least once.
Path Coverage: a test suite (collection of test cases), Verifies every execution path
is tested at least once.
Path Coverage > Branch Coverage > Statement Coverage.

6. Fault Injection Testing:

Introduces faults deliberately to check if tests detect them.
powerful testing approach.
After injection (usually a single injection per version), tests are executed against the
changed version (called mutant version).
Tests are then checked if it detects the change.