Skip to content

1. Introduction to Software Engineering , SDLC

Notes and definitions

  • software is written for people, not machines.
  • solving problems by an effective abstraction is the ultimate goal of software engineering.
  • technologies evolve and die, principles remain.

1.1 What is Software Engineering?

  • software engineering seems to require great emphasis on methodology or method for managing the development process.
  • problems can only be defined after they being solved.
  • Software engineering is often confused with programming
  • Software engineering is the creative activity of understanding the business problem, coming up with an idea for solution, and designing the “blueprints” of the solution.
  • Programming is the craft of implementing the given blueprints.
  • Some people say software engineering is about writing loads of documentation, Other people say software engineering is about writing a running code.
  • Software engineering is about:
    • understanding business problems,
    • inventing solutions,
    • evaluating alternatives,
    • making design tradeoffs and choices
    • document the whole process
    • largely about management: requires organizational and managerial skills
  • software engineering is full of problems which are:
    • all individual steps are easy,
    • yet the overall problem may be overwhelming

1.1.1 Why Software Engineering Is Difficult (1)

  • you meed to know about:
    • software domain.
    • problem domain.
  • software is formal domain, unlike most other domains. software requires everything to be defined precisely.
  • narrow-scope software engineering is concerned with the design, implementation, and testing of a program that represents a solution to the stated problem
  • broad-scope software engineering is to discover a solution for a real-world problem that has nothing to do with software domain.
  • abstractions are unavoidably just approximations, we cannot describe the problem domain in perfect detail

1.2 Software Development Life Cycle

  • The common software development life cycle is:

    1. Requirements specifications: understanding the usage scenarios of the static domain model.
    2. Design: assigning responsibilities to objects, and defining the dynamics of their behavior.
    3. Implementation: code.
    4. Testing
    5. Maintenance

  • software is:

    • intangible and hard to visualize
    • complex: contains large numbers of bits and small pieces of a smaller software
    • flexible: can be changed and modified at any stage

  • because of the above, linear development process (watterfall) is not a good idea, an incremental and iterative (evolutionary) development process is better.

  • incremental development process is:
    • beak down big problems into smaller problems
    • prioritize the most important problems
    • iterate over the small problems
    • use feedbacks to improve the solution over time
  • Incremental and iterative process seeks to get to a working instance as soon as possible.
  • having a working instance available allows other parties ti provide feedbacks and detect deficiencies.
  • Agile is Unified process follows the incremental and iterative process.
  • tools that facilitate communication between developers::
    • Modular design: break system into modules.
    • symbol language: use Unified Modeling Language (UML) to describe the system.
    • project and product metrics: measure the progress and the quality of the project.
    • design heuristics: design patterns that help to solve the problems.

1.2.1 Symbol Language

  • human short-term memory can store about 7 items at a time, in a process called chunking.
  • Diagrams and symbols are indispensible to the software engineer
  • UML website: https://www.omg.org/index.htm

1.2.2 Requirements analysis and System specification

  • starts with the customer statement of requirements.
  • then, the customer statement goes through requirements analysis .
  • requirements analysis is to understand the problem and delimit the scope.
  • the result of requirement analysis is elaborated requirements.
  • the end goal is to produce a system specification.
  • useCase modeling:
    • is a good technique for requirements analysis.
    • generates a set of use cases for individual parts of the system.
    • the user initiates actions and the system responds with reactions.
    • use case names usually starts with verbs.
    • we need to know what the system is supposed to do, not how to do it.

1.2.3 Object-Oriented Analysis and the Domain Model

  • next step is to build the domain model, by modelling the inside of the system.
  • the use cases will define the behavioral characteristics of the system, while the domain model will define the physical (structural) characteristics of the system.
  • we need to consider :
    • entities that are both external and internal to the software-to-be
    • The external environment constrains the problem to be solved and by implication constrains the internal design.
    • We also need to know what is implementable and what not,

1.2.4 Object-Oriented Design

  • the key activity in the design phase is assigning responsibilities to software objects.
  • software is a set of objects that communicate with each other to perform their roles.
  • Design is the creative process of searching how to implement all of the customer’s requirements.
  • Creativity and judgment are key for good software design.
  • 2 popular kinds of software designs: Maurits Escher and Rube Goldberg
  • Rube Goldberg design (an example of a bad design):
    • Rube design uses complex components with many unpredictable behaviors.
    • Rube design makes unrealistic assumptions.
    • Rube design uses unnecessary links (features or dependencies) to make the system more complex.
  • Recurring issues of software design include:
    • Design quality evaluation: Optimal design may be an unrealistic goal given the complexity of real-world applications.
    • finding a criteria for comparing the quality of possible designs.
    • Design for change: useful software lives for years and needs maintenance and modifications all the time.
    • Design for reuse: Reusing existing code and designs is economical and allows creating more sophisticated systems.
    • Design for security
    • Design for scalability.

1.2.5 Project Effort Estimation and Product Quality Measurement

  • use a relative-size estimate that measures how big individual sections are relative to one another.
  • the cost of estimation is exponential, improving the quality of the estimation beyond a certain point requires huge costs and efforts.
  • use incremental staging and scheduling strategy to quickly arrive at an effort estimate and to improve the development process quality.
  • use the iterative, rework scheduling strategy to improve the product quality.

1.3 Case Studies

  • concept maps are expressed in terms of concepts and propositions
  • example of concept map for “my friend is coding a new program”:
Proposition Concept Relation other Concept
1. I have friend
2. friend engages in coding
3. coding construct program
4. program is new

1.4 The Object model

  • Object is a software entity, package or module.
  • objects interact with each other to perform their roles, and provide services for other objects.
  • Objects have methods = functions = operations = procedures = subroutines.
  • method’s signature defines the method interface.
  • programs can follow:
    • procedural programming: define sequence of steps, and execute them one by one. it has global view(everything is global) so there is only the global object. it becomes unfeasible when the program is too complex.
    • object-oriented programming: define objects and their interactions. has a local view where each object deals with a subset of specific problems, and can consult other objects to delegate tasks.
  • assigning software responsibilities for software objects is the most important task for the software engineer.
  • the process to divide and conquer the problem into smaller ones can go under different names:
    • reductionism
    • modularity
    • structuralism
  • design is modular if:
    • each activity of the system is performed by exactly one unit.
    • inputs and outputs of each unit are well defined.

1.4.1 Controlling Access to Object Elements

  • encapsulation: hide the details of the implementation and the state of the object, so it can only be modified from within the object itself.

modules vs oop

  • getters and setters = accessors and mutators
  • access modifiers = access designations
modifier UML symbol function
public + attribute is visible everywhere
private - attribute is visible only within the object
protected # attribute is visible within the object and its subclasses
  • every object has 3 parts:
    • interface: defines the shape of the object (only the public part).
    • contract: the terms and conditions to use this object.
    • implementation: should be private or hidden.

1.4.2 Object Responsibilities and Relationships

  • inheritance: a child class inherits elements from a base (parent) class. static, defined at compile time, can not be changed.
  • composition: a class contains a reference to another class. dynamic, defined at run time, can be changed during the program run.

relationships between classes can be refined as:

  • Is-a-Relationship: UML symbol: ∆, indicates inheritance.
  • Has-a-Relationship:
    • Composition: UML symbol: ♦, the contained item (object) is an integral (direct) part of its container. eg. leg of a desk.
    • aggregation: UML symbol: ◊, the contained item (object) is a part of a collection in the container, but it can also exist on its own. eg. desk in an office (part of the office, an object on its own)
  • Uses-a-Relationship: UML symbol: ↓, a class uses another class
  • Creates-a-Relationship: calls the constructor of another class.

1.4.3 Reuse and Extension by Inheritance and Composition

  • polymorphism: the same method behaves differently on different subclasses of the same class.
  • Modular design was first introduced by David Parnas in 1960s.

2. Object-Oriented Software Engineering

  • we start requirements analysis we can use: use case modelling, Agile.
  • then we do domain modelling identifying the objects of our system
  • then the design and implementation of the system.
  • then the testing and shipping of the system.

2.1 Software Development Methods

  • development method works by mandating a sequence of development tasks.
  • development method main goals:
    • ensure that if some people left the project, the project should be able to continue as scheduled (Big Design Up Front BDUF).
  • development methods may ignored in practice, due to:
    • every software problem is unique so that it is hard to create a generalized approach that works for all problems
    • estimations quality evolves over time with doing the same steps repetitively, so a person can know in advance the time cost for each step.
    • development method takes time to evolve and become ‘mature’, by this time, the technologies that this method is based on may become outdated.
    • the method may be inappropriate for the technologies and marker conditions.
  • Four major software development methodologies can be classified as:
    • Structured Analysis and Design (SAD): 1960s - 1970s. functional decomposition and data-flow analysis for modelling.
    • Object-Oriented Analysis and Design (OOAD): 1980s - 1990s. useCases and UML for modelling.
    • Agile Software Development (ASD): 1990s - 2000s.
    • Aspect-Oriented Software Development (AOSD): 2000s. helps dealing with scattered concerns. divides program into core features and supplementary features that provide support for entities, connectivity, concurrency …etc. and they are called crosscutting concerns.

2..1.1 Agile Software Development

  • agile is result-focused, it prompts outcome-driven documentation and testing.
  • agile focuses on progressing light-weight carrying only things that are necessary at this stage.
  • agile manifesto: http://agilemanifesto.org/
  • agile recommends that development should be incremental and iterative with quick turnovers and light documentation.
  • agile does not replace methodologies such as structured analysis and design, OOP…etc. instead, it uses tools inherited from these methodologies but in a different way.
  • popular agile-development tool is user stories that represent the system requirements.
  • working code is the result of the developer’s design decisions but not the reasoning behind theses decisions.

2.1.2 Decisive Methodological Factors

  1. Traceability
  2. Testing
  3. Measurements
  4. Security

Traceability

  • explains how the entity evolved from this state to a new state (or version), and why the changes were made.
  • it is important to link source code back to useCase back to the customer requirements and vice versa. these links are the heart of traceability.
  • Traceability refers to the property of a software artifact, such as a use case or a class, of being traceable to the original requirement or rationale that motivated its existence.
  • treatability must be maintained across the lifecycle.

Testing

  • in TDD (Test Driven Development), development must start by a plan to verify how the result will meet the goal
  • any requirement which an automated program can not test it for compliance is a vague, subjective, contradictory and should be reconsidered.
  • you should not aim to just pass the test, and avoid other detailed analysis.
  • testing is used to test the program correctness and not the program quality.

Measurements

  • Software product metrics are intended to assess program quality.
  • Metrics do not uncover errors; they uncover poor design.

Security

  • security issues:
    • computer may be attacked, and sensitive data may be lost.
    • computer may be hijacked, where its resources are bing used to perform an unauthorized activity, such as spamming emails, …etc.
  • sources of security issues:
    • because of bad design or bad software: the computer itself is targeted.
    • because of network interconnectedness: the network is targeted, then all operation going through this network is infested.
  • developer must understand both: software and network security.
  • The Security Development Lifecycle (SDL), promoted by Microsoft and other software organizations, combines the existing approaches to software development with security-focused activities throughout the development lifecycle.