Analysis and design

Work in progress : more will be added

Sort of models for information systems

Sort of models for information systems

Models can be build :

• to document business requirements (analysis) or technical designs

• To automatically build prototype applications

• For existing software systems as a way to better understand those systems (i.e. reverse engineering)

Terminologies of domain model

• Classes

• Association

• Multiplicities ( * means 0 or more)

Use case purpose

Describes the behavior of the system in interaction with users and environment

Business use case (aka “Abstract-Level use case”)

• Describes the more general interaction between a business system and the users/actors of that system to produce business results of value

• System considered in business use case model may contain people in addition to technological system

• Example : sells book

System Use Case (Aka “implementation use case”)

• Describe show actors communicate with the (software) system to achieve their goalds

• Software system is the main subject (instead of business as a system)

• Example : Browse catalogue

🪁 Summary use case (Kite use case)

• Outline the context of a set of User Goal uses cases

• May have a step in its scenario for each Use Goal use case

• Help identifying high-level requirements, does not provide functional requirements

• Example : Complet Online Purchase Order

🌊 User goal use case (Sea use case)

• Can the actor go away happily after the use case finished ?

• Example : buy book or register customer

🐟 Subfunction use cases (fish level use cases)

• Created to move out an isolated part of a scenario to a separate use case

• Reusable in other use cases

• Example : log in

Use case diagram : extends

A → B

A extends the B use case

Use case diagram : include

A → B

A includes the B use case

Business process

Sequence of activities that produce a specific result for a particular customer of the process

Uml abbreviations for visibility

• • public

• ~ package

• #protected

• • private

Class diagram : Aggregation ◇-

Implies a relationship where the child can exist independently of the parent

• Example : Class (parent) and student (child)

Class diagram : Composition ◆-

Implies a relationship where the child cannot exist independent of the parent

• Example : house (parent) and room (child)

Transition label of state diagram

trigger-signature [guard]/activity

Requirement Engineering (RE)

Set of activities concerned with identifying and communicating the purpose of a software intensive system, and the context in which it will be used.

Hence, it acts as the bridge between the real world needs of users, customers, and other stakeholders affected by a software system, and the capabilities and opportunities afforded by software-intensive technologies.

How to do requirement engineering?

• Domain understanding and elicitation

• Evaluation and agreement

• Specification and documentation

• Validation and verification

This again if another alternative has been proposed

Truths of requirement engineering

• Requirement are not about the solution

• If we build software it must be optimally valuable for its owner

• If your software does not have to satisfy a need, then you can build anything.

• There is a difference between building a piece of software and solving a business problem. The former doesn’t necessarily solve the latter

Business requirements

Goals of the business like “increase profits”, “improve branding”, “become dominant in a market”…

User requirements

Goals or tasks of the users of software like “create purchase order”, “find a book my wife would like”

Functional requirements

Functionality that the software must include like “calculate profit-maximizing price” or “generate Sarbanes-Oxley compliance report” (what system must do)

Non-functional requirements

Characteristics that the software must show (how the system must do it)

How to identify stakeholders with STEP analysis

• Social variables

• Technological variables

• Economic variables

• Political variables in the environment.

Design principles SOLID :

• S ingle responsibility principle (SRP)

• O pen/closed principle (OCP)

• L iskov substitution principle (LSP)

• I nterface segregation principle (ISP)

• D ependency inversion principle (DIP)

Single responsibility principle (SRP)

Every object in your system should have a single responsibility and all the object’s services should be focused on carrying out that single responsibility.

(Think if the class can _____ itself )

Open/closed principle (OCP)

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

(Suggest more use of abstraction)

Liskov substitution principle (LSP)

Subtypes must be substitutable for their base types:

If T is a class and S is a subclass of T, then everywhere where you can use an instance of T in your program, you must be able to use an instance of S.

Interface segregation principles (ISP)

Following it means splitting up the fat interface into smaller so-called role interfaces.

Example : have interfaces named movable, feedable, workerIF…

Dependency inversion principle (DIP)

Principle: High-level modules should not depend on low-level modules. Both should depend on abstractions

Abstractions should not depend on details. Details should depend on abstractions.

Business process

Series of steps performed by a group of stakeholders to achieve a concrete goal

→ consists of task and activities that are assigned to a participant

BPMN

• Standard for process description/visualization

• Provides guidance, best practices

• Visualizes activities and information flow

• Is used for documentation and process optimization

Transition

A change from an originating state to a successor state as a result of some stimulus (typically events)

Event

Specification of a significant occurrence that has a location in time and space