SEF9 - 24 Software Design Concepts (Principles)

How can you design software if you do not know the concepts in software design?

IMPORTANT ADVICE:

As an example. When you read the User Requirements and Specifications (USR or URS) for the SVT system, you need to consider the following to execute its design. He he he. Actually, I considered everything below when I designed the SVT system. Got it? Ha ha ha.

SOFTWARE DESIGN 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:

1. 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.

2. Refinement - It is the process of elaboration. A hierarchy is developed by decomposing a macroscopic statement of function in a stepwise 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.

3. Modularity - Software architecture is divided into components called modules.

4. Software Architecture - It refers to the overall structure of the software and the ways in which that structure provides conceptual integrity for a system. A software architecture is the development work product that gives the highest return on investment with respect to quality, schedule and cost.

5. Control Hierarchy - A program structure that represent the organization of a program components and implies a hierarchy of control.

6. Structural Partitioning - The program structure can be divided both horizontally and vertically. Horizontal partitions define separate branches of modular hierarchy for each major program function. Vertical partitioning suggests that control and work should be distributed top down in the program structure.

7. Data Structure - It is a representation of the logical relationship among individual elements of data.

8. Software Procedure - It focuses on the processing of each modules individually

9. Information Hiding - Modules should be specified and designed so that information contained within a module is inaccessible to other modules that have no need for such information.

SOFTWARE DESIGN CONSIDERATIONS
===========================================================

There are many aspects to consider in the design of a piece of software. The importance of each should reflect the goals the software is trying to achieve. Some of these aspects are:

* Compatibility - The software is able to operate with other products that are designed for interoperability with another product. For example, a piece of software may be backward-compatible with an older version of itself. Consider EXTERNAL INTERFACES in FEDUPAAR.

* Extensibility - New capabilities can be added to the software without major changes to the underlying architecture. Consider FUNCTIONALITY, FUTURE USAGE in FEDUPAAR.

* Fault-tolerance - The software is resistant to and able to recover from component failure. Consider PERFORMANCE, USAGE in FEDUPAAR.

* Maintainability - The software can be restored to a specified condition within a specified period of time. For example, antivirus software may include the ability to periodically receive virus definition updates in order to maintain the software's effectiveness. Consider FUNCTIONALITY, FUTURE USAGE, PERFORMANCE in FEDUPAAR.

* Modularity - the resulting software comprises well defined, independent components. That leads to better maintainability. The components could be then implemented and tested in isolation before being integrated to form a desired software system. This allows division of work in a software development project. Consider WBS = WORK BREAK DOWN STRUCTURE in project management. Consider ATTRIBUTES, ASSUMPTIONS in FEDUPAAR.

* Packaging - Printed material such as the box and manuals should match the style designated for the target market and should enhance usability. All compatibility information should be visible on the outside of the package. All components required for use should be included in the package or specified as a requirement on the outside of the package. Consider REFERENCES in FEDUPAAR.

* Reliability - The software is able to perform a required function under stated conditions for a specified period of time. Consider PERFORMANCE, USAGE in FEDUPAAR.

* Reusability - the modular components designed should capture the essence of the functionality expected out of them and no more or less. This single-minded purpose renders the components reusable wherever there are similar needs in other designs. Consider FUNCTIONALITY, FUTURE USAGE in FEDUPAAR.

* Robustness - The software is able to operate under stress or tolerate unpredictable or invalid input. For example, it can be designed with a resilience to low memory conditions. Consider PERFORMANCE, USAGE in FEDUPAAR.

* Security - The software is able to withstand hostile acts and influences. Consider PERFORMANCE, USAGE in FEDUPAAR.

* Usability - The software user interface must be usable for its target user/audience. Default values for the parameters must be chosen so that they are a good choice for the majority of the users. Consider USAGE for CURRENT and FUTURE in FEDUPAAR.

MORE ISSUES ABOUT DESIGNS TO THINK ABOUT AND DEAL WITH
===========================================================

Various situations that we have to deal with in software design, like:

(1) design with local execution only (the usual standard and routine thing)
(2) design with concurrent and parallel execution (local and remote)
(3) design for control of hardware and events (periodic events, non-periodic events)
(4) design with distributed components (CBSE - COM+, DCOM, CORBA, JEEcomponents)
(5) design for error and exception handling
(6) design for fault-tolerance
(7) design for Interaction and Presentation
(8) design for Data Persistence


SYSTEM AND SOFTWARE ARCHITECTURAL DESIGN
===========================================================

(1) Decisions about software architectures
(2) How the overall system is organized
(3) Modular Decomposition Styles
(4) Control Styles
(5) Reference Architectures

DISTRIBUTED ARCHITECTURES

(1) Multiprocessor architectures (Multi-Core, Cluster Computing)
(2) Client-Server Architectures (Web Server, etc)
(3) Distributed Object Architectures (COM, DCOM, CORBA, JAVAEE , DOTNET WCF)
(4) Distributed Computing (Grid Computing, SOA, Peer-To-Peer)

APPLICATION ARCHITECTURES

(1) Data Processing Systems
(2) Transaction Processing Systems
(3) Event Processing Systems
(4) Language Processing Systems

OBJECT ORIENTED DESIGN

(1) Objects and Object Classes
(2) Object Oriented Design Process
(3) Object Oriented Design Evolution

REAL-TIME SOFTWARE DESIGN

(1) How the Overall System is Organized (Embedded Systems, Apollo-On-Board Computer, etc)
(2) RTOS - Real-Time Operating Systems (muCOS, RTAI, RTLinux, etc)
(3) Monitoring and Control Systems
(4) Data Acquisition Systems


===========================================================
Good Book 1 - Chapter 8 (Building the Analysis Model) Dr Roger Pressman.

When we study and analyze the SRS, we must determine which type of modeling best fits the SRS (requirements) for our application design.

All about understanding the requirements - translating them into models.

(1) Data Flow Modeling

DFD = Data Flow Diagram
ERD = Entity Relationship Diagram
Covers informain domain and functional domain.
etc

(2) Object Oriented Modeling

UML Class Diagram + Class Hierarchy
UML Relationship Diagram (Connecting lines)
UML Package Diagram
etc

(3) Scenario Based Modeling

UML Use Case Diagram
UML Activity Diagram
UML Swim Lane Diagram (combine Activity & Use-Case)
etc

(4) Behaviour Based Modeling

UML State Diagram
UML Transition Diagram (Events & Change of States)
Also DFD = Data Flow Diagram
Process Flow, Workflow, Business Flow, etc.
etc

(5) Design Patterns Based Modeling

Proven Design Templates
Solved Recurring Design Problems
Catalogued - Listed and Categorized (See EBook Design Patterns, Yahoo Design Patterns, Google Design patterns, etc) Just go study and pick those that fits our needs.

==========================================================
--
WASSALAM
wruslan.hahaha

Microsoft Word Version
Return to Software Engineering Fundamentals (SEF9MMUWRY)
Previous Topic: 23 Software Design Architectures (Is the future about Android?)
Next Topic: 25 SE Waterfall Model, Tun Dr Mahathir and the Four(4) Pees.