This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
Software design
Software design

Version management

Difference between version and

At line 1 added 39 lines
!!! Overview
[{$pagename}] is [design] of an [Application] and is typically part of the [Software Development Life Cycle]!! [{$pagename}] Concepts
The design concepts provide the software designer with a foundation from which more sophisticated methods can be applied. A set of fundamental design concepts has evolved. They are as follows:
* [Abstraction] - Abstraction is the process or result of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose.It is an act of Representing essential features without including the background details or explanations.
* [Refinement] - It is the process of elaboration. A [hierarchy] is developed by decomposing a macroscopic statement of function in a step-wise fashion until programming language statements are reached. In each step, one or several instructions of a given program are decomposed into more detailed instructions. [Abstraction] and Refinement are complementary concepts.
* [Modularity|Software library] - Software architecture is divided into components called [Software libraries|Software library] or [Functions].
* [Software] [Architecture] - refers to the overall structure of the software and the ways in which that structure provides conceptual integrity for a system. Good [Software Architecture Model] will yield a good return on investment with respect to the desired outcome of the project, e.g. in terms of performance, quality, schedule and cost.
* Control [Hierarchy] - A program structure that represents the organization of a program component and implies a [hierarchy] of control.
* Structural [Partitioning|Partition] - The program structure can be divided into both horizontally and vertically. Horizontal [partitions] define separate branches of modular hierarchy for each major program area of operation. Vertical partitioning suggests that control and work should be distributed top down in the program structure.
* [Data Structure] - It is a representation of the logical [relationship] among individual elements of [data].
* Software Procedure - It focuses on the processing of each [Function] individually.
* Information Hiding ([Encapsulation]) - [Functions] should be specified and designed so that information contained within a module is inaccessible to other modules that have no need for such information.
In his object model, Grady Booch mentions [Abstraction], [Encapsulation], [Modularisation|Software library], and [Hierarchy] as fundamental software design principles.[4] The acronym PHAME (Principles of [Hierarchy], [Abstraction], [Modularisation|Software library], and [Encapsulation]) is sometimes used to refer to these four fundamental principles.
Some will use the four fundamental principles adding [Polymorphism].
!! All [{$pagename}]
All [{$pagename}] has two primary items to deal with:
* [abstraction] of the [Data Structure]
* [communication] with other parts ([Bounded Contexts]) of the system!! [{$pagename}] [Requirements]
Each application has two categories of [requirements].
* [Functional Requirement]s - The functional requirements, are what the [{$pagename}] must do. They are usually in the form of [Use cases] or [User Story]. [Architecture] has little to do with the functional requirements. You can implement functional requirements with almost any [architecture], even a big ball of mud.
* [Non-functional requirement]s - Architecture is important because it enables an [application] to satisfy the define the Non-functional requirements such as runtime qualities such as scalability, and [reliability].
Non-functional requirements also define development time qualities including maintainability, testability, extensibility and deployability. The [architecture] that you choose for [{$pagename}] determines how well it meets these quality requirements.
!! [{$pagename}] [Architectures] [Classifications]
[{$pagename}] might be [classified|Classification] in many different [Architectures].
* [Imperative programming] - is a [{$pagename}] [Classification] that uses statements that change a program's [state]. Imperative programming focuses on describing __how__ a [application] operates.
** [procedural] which groups instructions into procedures,
** [Object-oriented Programming] which groups instructions together with the part of the __[state]__ they operate on,
* [Declarative programming] in which the programmer merely declares properties of the desired result, but not how to compute it
** [Functional Programming] in which the desired result is declared as the value of a series of [function] applications,
** [logic programming] is a type of programming paradigm which is largely based on formal logic. Any program written in a logic programming language is a set of sentences in logical form, expressing facts and rules about some problem domain.
** [mathematical programming] in which the desired result is declared as the solution of an optimization problem
** [Reactive programming] is the practice of programming with [asynchronous] data streams or [event] streams. [Observer] [Software design pattern].
** [Functional Reactive programming] the combination of functional and reactive paradigms. In other words, it is reacting to data streams using the functional paradigm. FRP is not a utility or a library — it changes the way you architect your applications and the way you think about your applications.!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop