Design and Quality

 

software design concepts

 1. Abstraction:-Abstraction is the act of representing essential features without including the background details or explanations. the abstraction is used to reduce complexity and allow efficient design and implementation of complex software systems. Many levels of abstraction can be posed.

 At the highest level of abstraction, a solution is stated in broad terms using the language of the problem environment. At lower levels of abstraction, a more detailed description of the solution is provided.

As different levels of abstraction are developed, you work to create both procedural and data abstractions. A procedural abstraction refers to a sequence of instructions that have a specific and limited function. The name of a procedural abstraction implies these functions, but specific details are suppressed. A data abstraction is a named collection of data that describes a data object. 

2. ARCHITECTURE- Architecture serves as a blueprint for a system.

Structure organization of program components (modules) and their interconnection 

The architectural design can be represented using one or more of a number of different models. Structural models: Represent architecture as an organized collection of program components. 

Framework models: Increase the level of design abstraction by attempting to identify repeatable architectural design frameworks that are encountered in similar types of applications. It represents the design in more abstract way 

Dynamic models : Address the behavioral aspects of the program architecture, indicating how the structure or system configuration may change as a function of external events. 

Process models :Focus on the design of the business or technical process that the system must accommodate.

 Functional models can be used to represent the functional hierarchy of a system.

3. Pattern- a repeated form

The pattern simply means a repeated form or design in which the same shape is repeated several times to form a pattern. The pattern in the design process means the repetition of a solution to a common recurring problem within a certain context.

4. REFINEMENT 

 Process of elaboration from high level abstraction to the lowest level abstraction. High level abstraction begins with a statement of functions. Refinement causes the designer to elaborate providing more and more details at successive level of abstractions Abstraction and refinement are complementary concepts.

5. Refactoring -- Organization technique that simplifies the design of a component without changing its function or behavior. a reorganization technique that simplifies the design. Examines for redundancy, unused design elements and inefficient or unnecessary algorithms.  

6. Modularity

• A software is separately divided into name and addressable components. Sometime they are called as modules which integrate to satisfy the problem requirements.
• Modularity is the single attribute of a software that permits a program to be managed easily.

7. Information hiding
Modules must be specified and designed so that the information like algorithm and data presented in a module is not accessible for other modules not requiring that information.

8. Functional independence 

A module having high cohesion and low coupling is said to be functionally independent of other modules. By the term functional independence, we mean that a cohesive module performs a single task or function. A functionally independent module has minimal interaction with other modules.

Software Design

Software Design 

Software design,

Preliminary and detailed design activities,

Difference between analysis and design

Items developed during the software design phase

Characteristics of a good software design

Features of a design document  

Flow oriented model

 

Behavioral Model

 Behavioral Model is specially designed to make us understand behavior and factors that influence behavior of a System. 

Behavioral models are models of the dynamic behavior of the system as it is executing.

Behavioral models describe the internal behavior of a system

Class-Responsibility-Collaborator (CRC) Modeling

 Class-Responsibility-Collaborator (CRC) Modeling

Class-responsibility-collaborator (CRC) modeling [Wir90] provides a simple means for identifying and organizing the classes that are relevant to system or product requirements. Ambler [Amb95] describes CRC modeling in the following way: 

"A CRC model is really a collection of standard index cards that represent classes. The cards are divided into three sections. Along the top of the card you write the name of the class. In the body of the card you list the class responsibilities on the left and the collaborators on the right."

In reality, the CRC model may make use of actual or virtual index cards. The intent is to develop an organized representation of classes. 

Responsibilities are the attributes and operations that are relevant for the class. Stated simply, a responsibility is “anything the class knows or does” [Amb95].

 Collaborators are those classes that are required to provide a class with the information needed to complete a responsibility. In general, a collaboration implies either a request for information or a request for some action.

A simple CRC index card for the FloorPlan class is illustrated in Figure 6.11. The list of responsibilities shown on the CRC card is preliminary and subject to additions or modification. The classes Wall and Camera are noted next to the responsibility that will require their collaboration.

CLASS-BASED MODELING

 What is class based modeling 

Class-based modeling represents the objects that the system will manipulate, the operations (also called methods or services) that will be applied to the objects to effect the manipulation, relationships.

Class-oriented models that represent object-oriented classes (attributes and operations) and the manner in which classes collaborate to achieve system requirements 

Use Case

 https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-use-case-diagram/

Software Metrics and Measures

 Software Measures can be understood as a process of quantifying and symbolizing various attributes and aspects of software.

Software Metrics provide measures for various aspects of software process and software product.

Software measures are fundamental requirement of software engineering. They not only help to control the software development process but also aid to keep quality of ultimate product excellent.

According to Tom DeMarco, a (Software Engineer), “You cannot control what you cannot measure.” By his saying, it is very clear how important software measures are.

Let us see some software metrics:

• Size Metrics - LOC (Lines of Code), mostly calculated in thousands of delivered source code lines, denoted as KLOC.

  Function Point Count is measure of the functionality provided by the software. Function Point count defines the size of functional aspect of software.

• Complexity Metrics - McCabe’s Cyclomatic complexity quantifies the upper bound of the number of independent paths in a program, which is perceived as complexity of the program or its modules. It is represented in terms of graph theory concepts by using control flow graph.

• Quality Metrics - Defects, their types and causes, consequence, intensity of severity and their implications define the quality of product.

  The number of defects found in development process and number of defects reported by the client after the product is installed or delivered at client-end, define quality of product.

• Process Metrics - In various phases of SDLC, the methods and tools used, the company standards and the performance of development are software process metrics.
• Resource Metrics - Effort, time and various resources used, represents metrics for resource measurement.

Software System Analyst

 

Software System Analyst

System analyst in an IT organization is a person, who analyzes the requirement of proposed system and ensures that requirements are conceived and documented properly & correctly. Role of an analyst starts during Software Analysis Phase of SDLC. It is the responsibility of analyst to make sure that the developed software meets the requirements of the client.

System Analysts have the following responsibilities:

• Analyzing and understanding requirements of intended software
• Understanding how the project will contribute in the organization objectives
• Identify sources of requirement
• Validation of requirement
• Develop and implement requirement management plan
• Documentation of business, technical, process and product requirements
• Coordination with clients to prioritize requirements and remove and ambiguity
• Finalizing acceptance criteria with client and other stakeholders