This site is from a past semester! The current version will be here when the new semester starts.

Week 2 [Mon, Jan 16th] - SE Topics

Detailed Table of Contents

Guidance for the item(s) below:

While you are learning Python basics, let's also take a look at some other SE topics that we need to cover. In the early weeks, we try to cover SE topics somewhat independent from the programming topics being covered so that if you are slow on the programming side, you can still make progress on the SE side.

To start, let's look at the design aspect, and abstraction which is a concept most fundamental to the design aspect (and to many other aspects of SE).

[W2.1] Design: Basics


Introduction

W2.1a

Design → Introduction → What

Can explain what is software design

Design is the creative process of transforming the problem into a solution; the solution is also called design. -- 📖 Software Engineering Theory and Practice, Shari Lawrence; Atlee, Joanne M. Pfleeger

Software design has two main aspects:

  • Product/external design: designing the external behavior of the product to meet the users' requirements. This is usually done by product designers with input from business analysts, user experience experts, user representatives, etc.
  • Implementation/internal design: designing how the product will be implemented to meet the required external behavior. This is usually done by software architects and software engineers.


Abstraction

W2.1b

Design → Design Fundamentals → Abstraction → What

Can explain abstraction

Abstraction is a technique for dealing with complexity. It works by establishing a level of complexity we are interested in, and suppressing the more complex details below that level.

The guiding principle of abstraction is that only details that are relevant to the current perspective or the task at hand need to be considered. As most programs are written to solve complex problems involving large amounts of intricate details, it is impossible to deal with all these details at the same time. That is where abstraction can help.

Data abstraction: abstracting away the lower level data items and thinking in terms of bigger entities

Within a certain software component, you might deal with a user data type, while ignoring the details contained in the user data item such as name, and date of birth. These details have been ‘abstracted away’ as they do not affect the task of that software component.

Control abstraction: abstracting away details of the actual control flow to focus on tasks at a higher level

print(“Hello”) is an abstraction of the actual output mechanism within the computer.

Abstraction can be applied repeatedly to obtain progressively higher levels of abstraction.

An example of different levels of data abstraction: a File is a data item that is at a higher level than an array and an array is at a higher level than a bit.

An example of different levels of control abstraction: execute(Game) is at a higher level than print(Char) which is at a higher level than an Assembly language instruction MOV.

Abstraction is a general concept that is not limited to just data or control abstractions.

Some more general examples of abstraction:

  • An OOP class is an abstraction over related data and behaviors.
  • An architecture is a higher-level abstraction of the design of a software.
  • Models (e.g., UML models) are abstractions of some aspect of reality.

Guidance for the item(s) below:

Software engineers often have to write developer documentation to explain their work to others. One important objective of developer documentation is to explain the design and the implementation of the software, which usually uses diagrams as models of the design being described.

Let's learn what models are, and how they are useful even beyond mere documentation.

[W2.2] Design: Models

W2.2a

Design → Modelling → Introduction → What

Can explain models

A model is a representation of something else.

A class diagram is a model that represents a software design.

A model provides a simpler view of a complex entity because a model captures only a selected aspect. This omission of some aspects implies models are abstractions.

A class diagram captures the structure of the software design but not the behavior.

Multiple models of the same entity may be needed to capture it fully.

In addition to a class diagram (or even multiple class diagrams), a number of other diagrams may be needed to capture various interesting aspects of the software.

W2.2b

Design → Modelling → Introduction → How

Can explain how models are used

In software development, models are useful in several ways:

a) To analyze a complex entity related to software development.

Some examples of using models for analysis:

  1. Models of the can be built to aid the understanding of the problem to be solved.
  2. When planning a software solution, models can be created to figure out how the solution is to be built. An architecture diagram is such a model.

b) To communicate information among stakeholders. Models can be used as a visual aid in discussions and documentation.

Some examples of using models to communicate:

  1. You can use an architecture diagram to explain the high-level design of the software to developers.
  2. A business analyst can use a use case diagram to explain to the customer the functionality of the system.
  3. A class diagram can be reverse-engineered from code so as to help explain the design of a component to a new developer.

c) As a blueprint for creating software. Models can be used as instructions for building software.

Some examples of using models as blueprints:

  1. A senior developer draws a class diagram to propose a design for an OOP software and passes it to a junior programmer to implement.
  2. A software tool allows users to draw UML models using its interface and the tool automatically generates the code based on the model.
Model Driven Development extra

Exercises

Guidance for the item(s) below:

Activity diagrams is the first UML diagram type you'll be learning in this module, and probably the easiest and most intuitive of the lot. You've heard about 'flow charts', right? Well, this is the UML equivalent of that.

[W2.3] Activity Diagrams

Video

W2.3a

Design → Modelling → Modelling Behaviors Activity diagrams - basic

Can use basic-level activity diagrams

Software projects often involve workflows. Workflows define the flow in which a process or a set of tasks is executed. Understanding such workflows is important for the success of the software project.

Some examples in which a certain workflow is relevant to software project:

A software that automates the work of an insurance company needs to take into account the workflow of processing an insurance claim.

The algorithm of a piece of code represents the workflow (i.e. the execution flow) of the code.

UML Activity Diagrams → Introduction → What

UML Activity Diagrams → Basic Notation → Linear Paths

UML Activity Diagrams → Basic Notation → Alternate Paths

UML Activity Diagrams → Basic Notation → Parallel Paths

Exercises

Which sequences are not allowed?

Model the algorithms of calculating grades

Model workflow of a Burger shop

W2.3b : OPTIONAL

Design → Modelling → Modelling Behaviors Activity diagrams - intermediate