Please enable JavaScript.
Coggle requires JavaScript to display documents.
Topic 2: Foundations in Software Design - Coggle Diagram
Topic 2: Foundations in Software Design
Agenda 1: Motivation, Impact of Software Design
Introduction
What is Design?
it is between analysis and specification phase and implementation test and maintenance
Design is a part of the software development life cycle
What are the inputs
and outputs
of the Design phase?
Input
SRS. After collecting all requirements
from the client and are
elicited in the form of an SRS.
During
Bring SRS to design team, especially software architect.
Output
SDD. Then given to implementation, test, & maintenance
Design levels
Architectural design /
top level /
high level
What is Architectural design?
concerned with understanding how software systems should be organized and designing on the overall structure of the system
Purpose?
Architecture design is the critical link between the design and the RE as it it defines the main structure components in the system and the relationships between them
Output
Architecture model to describe how the system is organized and a set of communicating components
Detailed Design (use design patterns such as facade, prototype, factory, builder)
Advantages of Software Design
Stakeholder communications: architecture may be used as a focus of discussion by system stakeholder. Everyone will have the same view of how the system works and looks like
system analysis: means the analysis of whether the system can make its non-fashion requirements possible. Each design pattern has its quality focus that it sustains. Example: MVC => iterative representation and flexible, more secure
Large scale reuse: any goal of a system is to be reusable, to have reusable components of the system.
a. The architecture of the system to be developed may be reusable across a range of systems.
b. Product line architectures may be also developed with a proper design
Use of Design
a way of facilitating discussion about the system design: a high-level architecture view of a system is useful for communications with system stakeholders and project planning because it's not cluttered with details. stakeholders can relate to it and understand an abstract view of the system they can then discuss the system as a whole without being confused by details. Just showing them the component diagram or the architectural pattern (MVC, layered) it is easier for them to understand the diagram and give a feedback based on the design,
as a way of documenting an architecture that has been designed : the aim here is to produce a complete system model that shows the different components system the interface and their connections
Influence of software architecture to qualities?
Design focuses on a number of quality factors. one of the most important software qualities that software design focus on is changeability
changeability: Laws of Software Evolution
Lehman's first law of software evolution
Continuing Change
a program that is used and that as an implementation of this specification reflects some reality undergoes continual change or becomes progressively less useful.
The system will change over its live time.
(— Software systems must be continuously changed to adapt to the environment)
Lehman's second law of software evolution
Increased Complexity
as an evolving program changes its structures become more complex extra resources must be devoted to preserving and simplifying the structure.
A software architecture must cope with change.
(— Changes increase the complexity of software.)
Concepts and Terminology
System - component
What is System?
is a collection of components organized to accomplish a specific function of set of functions
What is Software component?
it's an architectural entity that means that it must be designed for certain architecture or standard architecture that
encapsulate a subset of system functionality and data
restrict access to that subset via an explicitly defined interface
has explicitly defined dependency on its required execution context
We can conclude that the properties of
software components are as follows:
encapsulation or information hiding of properties
offer a set of service via an interface (provided interface)
need services of other components (required interface)
Client-server relation
What is interface?
the boundary between two communicating components. the interface offers the service of the component to the environment and/or requires service needed by other components
interface is defined by a respective interface descriptions
syntax and of communication
pre and post condition
general quality aspects
interface discussion language(IDL)
What is software architecture?
is the structure(s) of the system which
comprise software elements the externally
visible properties
of those elements and the relationship
among them
arch. has several arch. structures (views)
each structure is modeled by means of software elements and their relationships.
All external properties of all software elements needed for interaction of the components need to be defined.
What is View?
expresses the architecture of the system from the perspective of one or more stakeholders to address specific concern using the convention established by its viewpoint
a collection of models that represent one aspect of an entire system (it only applies to one concrete system)
Dynamic view: show the collaboration and the communications between these components (e.g. seq. diagram & state diagram)
Deployment view: show how the components are mapped to infrastructure and (e.g. deployment diagram)
Static view: defines the component(e.g. class diagram) and their relations and interfaces and it has to be refined
System View: shows how the new system is embedded in the existing IT landscapes. it defines the system boundary and its external interfaces
What is Viewpoint?
Set of conventions for constructing, interpreting, using and analyzing one type of architecture view.
establish the languages or notations used to create the view
Information needs
Architectural Description - ADL
What is Architectural description?
Is a model - document, product or other artifact - to communicate and record a system's architecture. An architectural description conveys a set of views each of which depicts the system by describing domain concerns.
What is Architecture description language?
An ADL focuses on the high-end structure of the overall application rather than the implementation details of any specific source module. ADLs provide both a concrete syntax and a conceptual framework for modelling a software system's conceptual architecture.
Uses of Architectural description
Analysis of alternative architectures
Business planning for transition from a legacy architecture to a new architecture (e.g. from layered to mvc)
Communications among organizations involved in the development, production, fielding, operation, and maintenance of a system
Criteria for certifying conformance of implementations to the
architecture
Development and maintenance documentation, including material for reuse repositories and training materials
Input to subsequent design and development activities
Review, analysis, and evaluation of the system across the life cycle
Design Principles
Separation of Concerns (SoC)
What is Separation of Concerns (SoC)?
is the process of breaking a computer program into distinct features that overlap in functionality as little as possible. A concern is any piece of interest or focus in a program. Typically, concerns are synonymous with features or behaviors. ( it is much more manageable and reusable when the program is broken down). SoC allows that explicitly modeled features can be assigned to products and documents in a flexible manner.
Single Responsibility Principle (SRP)
every object should have a single responsibility, and that all its services should be narrowly aligned with that responsibility. On some level Cohesion is considered as synonym for SRP.
Some benefits of SoC and SRP
Allow people to work on individual parts of the system in isolation
Facilitate reusability
Ensure the maintainability of a system
Facilitate to add new features easily
Enable everyone to better understand the system
Hierarchical Decomposition
What is Hierarchical Decomposition?
Structure of elements ordered by means of a (hierarchy forming) relationship. Hierarchies are proven structures to reduce complexity!
Types
Monohierarchy
Every element (without the root element) has exactly one higher-ranked element (e.g. Tree)
Polyhierarchy
Every element may have multiple
higher-ranked elements (e.g. acyclic directed graph)
Kinds
Aggregation hierarchy
Represents "whole-part" relations. Usually monohierarchies
Generalization hierarchy
Orders elements from abstract to concrete, from general to special. Mono- or polyhierarchies
Hierarchy of levels
Each level has at most one lower-ranking and at most one higher-ranking level. Stronger variant of a monohierarchy
Open-closed Principle
Open Closed with non OO
What is Open-closed Principle?
Software entities like classes, modules and functions should be open for extension but closed for modifications.
open
The unit is open for extension. according to new requirements the unit can be extended to behave in new and different ways.
Closed
The code of the unit is stable, it can be used by clients. No one is allowed to make changes to the code (interface). the unit can be used without risk.
Application in an object oriented paradigm
The Open-Closed principle can be applied in object oriented design by inheritance / polymorphism
Approach
The interface of the module A becomes an abstract class A If needed new subclasses of A can be derived; these subclasses may extend A
principle of redundancy (without redundancy)
"A design should be without redundancy"
Design Rules
Direct mapping:The structure of the design should relate closely to the structures
Few interfaces: Every unit should communicate with as few others as possible. Each unit should be loosely coupled
Small interfaces: If two units communicate, they should exchange as little information as possible
Explicit interfaces : Whenever two units A and B communicate, this must be obvious from the text of A or B or both. i.e., declare all imports explicitly
Hide information: Only relevant information should be accessible.
Properties of good Designs
sufficient: Each unit has all the features needed for a sensible and efficient usage within the abstraction; the interface is as small as possible. (no duplications)
complete: Each unit has all relevant features within the abstraction; a general interface can be reused. ((al the requirements are made)
simple: All features of a unit are easy to understand (and implement); complex features are built up of simpler features.
plausible: The decomposition of units can be easily and intuitively be understood
composable: Design software units which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed
understandable: Design software in which a human reader can understand each unit without having to know the others, or, at worst, by having to examine only a few of the others.
continuous (local): A small change in a problem specification will trigger a change of just one unit, or a small number of units.
Loose Coupling: The relationship between different components. The coupling should be as loose as possible.
Strong Cohesion: The relationship of the elements within a component. The cohesion should be as strong (high) as possible.
ARCHITECTURAL PATTERN
