Embedded Files
Syllabus: Unit-4
Design within the Context of Software Engineering, The Design Process, Design Concepts, The Design Model, Software Architecture, Architectural Genres, Architectural Styles, Assessing Alternative Architectural Designs, Architectural Mapping Using Data Flow, Components, Designing Class-Based Components, Conducting Component-Level Design, Component-Level Design for WebApps, Designing Traditional Components, Component-Based Development.
Text Book-I: Chapters 8, 9, 10.
TOPICS:
Design Concepts
4.1 Design within the Context of Software Engineering
4.2 The Design Process
4.3 Design Concepts
4.4 The Design Model
Architectural Design
4.5 Software Architecture
4.6 Architectural Genres
4.7 Architectural Styles
4.8 Assessing Alternative Architectural Designs
4.9 Architectural Mapping Using Data Flow
Component-level Design
4.10 Components
4.11 Designing Class-Based Components
4.12 Conducting Component-Level Design
4.13 Component-Level Design for Web Apps
4.14 Designing Traditional Components
4.15 Component-Based Development.
4.1 Design within the Context of Software Engineering
why is design so important? => Answer is a single word—quality.
interface design => software communicates with systems(interoperation) and humans (who use it).
The architectural design => major structural elements of s/w, the architectural styles, design patterns, constraints
The data/class => transforms class models to design class realizations (the imp data structures to implement the s/w)
The component-level design = structural elements of the software architecture procedural description of software components.
4.2 The Design Process
Quality Guidelines
1. A design should exhibit an architecture that:
(a) recognizable architectural styles or patterns
(b) is composed of components that exhibit good design characteristics
(c) thereby facilitating implementation and testing.
2. A design = modular (logically partitioned into elements or subsystems)
3. A design = contain distinct representations of data, architecture, interfaces, and components
4. design = data structures appropriate for the classes to be implemented
5. A design should lead to components that have independent functional characteristics.
6. A design should lead to interfaces that reduce the complexity of connections and with the external environment.
7. A design = derived using a repeatable method that is driven by information obtained during software requirements analysis.
8. A design = notation that effectively communicates its meaning.
Quality Attributes
Functionality is assessed by evaluating the feature set, capabilities, generality and security of the overall system.
Usability is assessed by considering human factors, overall aesthetics, consistency, and documentation.
Reliability is evaluated by measuring the frequency and severity of failure, the accuracy of output results, the mean-time-to-failure (MTTF), the ability to recover from failure, and the predictability of the program.
Performance is measured by considering processing speed, response time, resource consumption, throughput, and efficiency.
Supportability combines the ability to extend the program (extensibility), adaptability, serviceability—these three attributes represent a more common term, maintainability—and in addition, testability, compatibility, configurability, the ease with which a system can be installed, and the ease with which problems can be localized.
The Evolution of Software Design
Refining software structures in a top-down manner.
software design =emphasis on software architecture + the design patterns
Number of design methods, growing out of the work just noted, are being applied throughout the industry
Common characteristics:
(a) requirements model design representation
(b) notation = represent functional components and their interfaces
(c) shortcuts for refinement and partitioning
(d) guidelines for quality assessment
4.3 Design Concepts (AAPS MIFR AROD)
Abstraction: * A procedural abstraction refers to a sequence of instructions that have a specific and limited function
* A data abstraction is a named collection of data that describes a data object
* Data Abstraction = Door; then procedural abstraction= open
Architecture:
* architecture is the structure or organization of program components (modules)
* Components = major system elements set of architectural patterns enables a software engineer to solve common design problems
* Structural models = architecture as an organized collection of program components
* Dynamic models = behavioral aspects of system config change due to external events.
* Process models= focus on the design of the business or technical process of the system
* Functional models = represent the functional hierarchy of a system
* Architectural Description Languages (ADLs) = developed to represent these models
Patterns:
* A pattern is a named nugget of insight which conveys the essence of a proven solution to a recurring problem within a certain context amidst competing concerns
* The intent of each design pattern is to provide a description that enables a designer to determine:
(1) whether the pattern is applicable to the current work,
(2) whether the pattern can be reused (hence, saving design time), and
(3) whether the pattern can serve as a guide for developing a similar, but functionally or structurally different pattern
Separation of Concerns:
* A concern is a feature or behavior that is specified as part of the requirements model for the software
* Separation of concerns is a design concept that suggests that any complex problem can be more easily handled if it is subdivided into pieces that can each be solved and/or optimized independently
Modularity:
* Software is divided into separately named and addressable components, sometimes called modules, that are integrated to satisfy problem requirements.
Refinement:
* Refinement helps to reveal low-level details as design progresses. It is actually a process of elaboration
* Abstraction enables to specify procedure and data internally but suppress the need for “outsiders” to have knowledge of low-level details
Aspects:
* If requirements analysis is done, then a set of “concerns” is uncovered.
* An aspect is a representation of a crosscutting concern.
* Req-A, Req-B: B can not be satisfied w/o taking A into consideration; => A crosscuts B.
Refactoring:
* Refactoring is a reorganization technique that simplifies the design (or code) of a component without changing its function or behavior
OOD Concepts:
* OO design concepts such as classes and objects, inheritance, messages, and polymorphism
Design Classes:
* design classes that refine the analysis classes by providing design detail that will enable the classes to be implemented and implement a software infrastructure that supports the business solution.
User interface classes define all abstractions that are necessary for human computer interaction (HCI). In many cases, HCI occurs within the context of a metaphor (e.g., a checkbook, an order form, a fax machine), and the design classes for the interface may be visual representations of the elements of the metaphor.
Business domain classes are often refinements of the analysis classes defined earlier. The classes identify the attributes and services (methods) that are required to implement some element of the business domain.
Process classes implement lower-level business abstractions required to fully manage the business domain classes.
Persistent classes represent data stores (e.g., a database) that will persist beyond the execution of the software.
System classes implement software management and control functions that enable the system to operate and communicate within its computing environment and with the outside world.
Complete and sufficient: A design class should be the complete encapsulation of all attributes and methods that can reasonably be expected (based on a knowledgeable interpretation of the class name) to exist for the class
Primitiveness: Methods associated with a design class should be focused on accomplishing one service for the class. Once the service has been implemented with a method, the class should not provide another way to accomplish the same thing.
High cohesion: A cohesive design class has a small, focused set of responsibilities and single-mindedly applies attributes and methods to implement those responsibilities.
Low coupling: Within the design model, it is necessary for design classes to collaborate with one another. However collaboration should be kept to an acceptable minimum
Design class for FloorPlan and composite aggregation for the class:
4.4 The Design Model
The design model can be viewed in two different dimensions:
process dimension indicates the evolution of the design model
abstraction dimension represents the level of detail as each element
Data Design Elements
a.Like other software engineering activities, data design (sometimes referred to as data architecting) creates a model of data and/or information that is represented at a high level of abstraction (the customer/user’s view of data).
b.This data model is then refined into progressively more implementation-specific representations that can be processed by the computer-based system.
c.At the program component level, the design of data structures and the associated algorithms required to manipulate them is essential to the creation of high-quality applications
d.At the application level, the translation of a data model (derived as part of requirements engineering) into a database is pivotal to achieving the business objectives of a system.
e.At the business level, the collection of information stored in disparate databases and reorganized into a “data warehouse” enables data mining or knowledge discovery that can have an impact on the success of the business itself.
Architectural Design Elements
a. Architectural design elements give us an overall view of the software.
b. The architectural model is derived from three sources:
(1) information about the application domain for the software to be built;
(2) specific requirements model elements such as data flow diagrams or analysis classes, their relationships and collaborations for the problem at hand; and
(3)the availability of architectural styles and patterns.
c. The architectural design element is usually depicted as a set of interconnected subsystems, often derived from analysis packages within the requirements model.
d. Each subsystem may have it’s own architecture.
Interface Design Elements
a. The interface design elements for software depict information flows into and out of the system and how it is communicated among the components defined as part of the architecture.
b.There are three important elements of interface design:
(1) the user interface (UI);
(2) external interfaces to other systems, devices, networks, or other producers or consumers of information; and
(3) internal interfaces between various design components.
c. These interface design elements allow the software to communicate externally and enable internal communication and collaboration among the components that populate the software architecture.
d. UI design (increasingly called usability design) is a major software engineering action. Usability design incorporates aesthetic elements (e.g., layout, color, graphics, interaction mechanisms), ergonomic elements.(e.g., information layout and placement, metaphors, UI navigation), and technical elements (e.g., UI patterns, reusable components).
Component-Level Design Elements
a.The component-level design for software fully describes the internal detail of each software component. To accomplish this, the component-level design defines data structures for all local data objects and algorithmic detail for all processing that occurs within a component and an interface that allows access to all
component operations (behaviors).
b.The design details of a component can be modeled at many different levels of abstraction. A UML activity diagram can be used to represent processing logic. Detailed procedural flow for a component can be represented using either pseudocode or some other diagrammatic form (e.g., flowchart or box diagram). Algorithmic structure follows the rules established for structured programming (i.e., a set of constrained procedural constructs).
Deployment-Level Design Elements
Deployment-level design elements indicate how software functionality and subsystems will be allocated within the physical computing environment that will support the software.
For example, the elements of the SafeHome product are configured to operate within three primary computing environments—a home-based PC, the SafeHome control panel, and a server housed at CPI Corp. (providing Internet-based access to the system).
4.5 Software Architecture:
* What is Software Architecture? The software architecture of a program comprise software components
*Why Architecture is important?
The architecture=representation (only, but not program) enabling:
#enabler for communication between all parties (stakeholders)
# early design decisions that will have a profound impact on all software engineering work
# define model that details how its components work together
• Architectural Descriptions:
#Representations of software architecture are an enabler for communication between all
#architectural description is actually a set of work products that reflect different views of the system parties (stakeholders) interested in the development of a computer-based system.
• Architectural Decisions: architectural decisions themselves can be considered to be one view of the architecture.
4.6 Architectural Genres:
=> specific architectural approach to the structure that must be built ==> each genre represents a unique challenge
Following are architectural genres for software-based systems:
• Artificial intelligence—Systems that simulate or augment human cognition, locomotion, or other organic processes.
• Commercial and nonprofit—Systems that are fundamental to the operation of a business enterprise.
• Communications—Systems that provide the infrastructure for transferring and managing data, for connecting users of that data, or for presenting data at the edge of an infrastructure.
• Content authoring—Systems that are used to create or manipulate textual or multimedia artifacts.
• Devices—Systems that interact with the physical world to provide some point service for an individual.
• Entertainment and sports—Systems that manage public events or that provide a large group entertainment experience.
• Financial—Systems that provide the infrastructure for transferring and managing money and other securities.
• Games—Systems that provide an entertainment experience for individuals or groups.
• Government—Systems that support the conduct and operations of a local, state, federal, global, or other political entity.
• Industrial—Systems that simulate or control physical processes.
• Legal—Systems that support the legal industry.
• Medical—Systems that diagnose or heal or that contribute to medical research.
• Military—Systems for consultation, communications, command, control, and intelligence (C4I) as well as offensive and defensive weapons.
• Operating systems—Systems that sit just above hardware to provide basic software services.
• Platforms—Systems that sit just above operating systems to provide advanced services.
• Scientific—Systems that are used for scientific research and applications.
• Tools—Systems that are used to develop other systems.
• Transportation—Systems that control water, ground, air, or space vehicles.
• Utilities—Systems that interact with other software to provide some point service
4.7 Architectural Styles:
* An architectural style is a transformation that is imposed on the design of an entire system.
* The software that is built for computer-based systems also exhibits one of many
architectural styles. Each style describes a system category that encompasses
# a set of components (e.g., a database, computational modules) that perform a function required by a system;
# a set of connectors that enable “communication, coordination and cooperation” among components;
# constraints that define how components can be integrated to form the system
# semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts
A Brief Taxonomy of Architectural Styles
Fig: Data Centric Architecture
Fig: Data-Flow Architecture
Fig: Main Program/ Syb-Program Architecture
Fig: Layered Architecture
Architectural Patterns
Architectural patterns address an application-specific problem within a specific context and under a set of limitations and constraints
Organization and Refinement
* Control: How is control managed within the architecture? hierarchy ? topology ? synchronized ?
* Data: How are data communicated between components?
4.8 Assessing Alternative Architectural Designs
An Architecture Trade-Off Analysis Method (ATAM)
The design analysis activities that follow are performed iteratively:
1. Collect scenarios: A set of use cases is developed to represent the system from the user’s point of view.
2. Elicit requirements, constraints, and environment description: This information is determined as part of requirements engineering and is used to be certain that all stakeholder concerns have been addressed.
3. Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements. The architectural style(s) should be described using one of the following architectural views:
• Module view for analysis of work assignments with components and the degree to which
information hiding has been achieved.
• Process view for analysis of system performance.
• Data flow view for analysis of the degree to which the architecture meets functional requirements.
4. Evaluate quality attributes by considering each attribute in isolation The number of quality attributes chosen for analysis is a function of the time available for review and the degree to which quality attributes are relevant to the system at hand. Quality attributes for architectural design assessment include reliability, performance, security, maintainability, flexibility, testability, portability, reusability, and interoperability.
5. Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style: This can be accomplished by making small changes in the architecture and determining how sensitive a quality attribute, say performance, is to the change. Any attributes that are significantly affected by variation in the architecture are termed sensitivity points.
6. Critique candidate architectures (developed in step 3) using the sensitivity analysis conducted in step 5: The SEI describes this approach in the following manner:
For example, the performance of a client-server architecture might be highly sensitive to the number of servers (performance increases, within some range, by increasing the number of servers). . . . The number of servers, then, is a trade-off point with respect to this architecture.
Architectural Complexity
Sharing dependencies represent dependence relationships among consumers who use the same resource or producers who produce for the same consumers. For example, for two components u and v, if u and v refer to the same global data, then there exists a shared
dependence relationship between u and v
Flow dependencies represent dependence relationships between producers and consumers of resources. For example, for two components u and v, if u must complete before control flows into v (prerequisite), or if u communicates with v by parameters, then there
exists a flow dependence relationship between u and v.
Constrained dependencies represent constraints on the relative flow of control among a set of activities. For example, for two components u and v, u and v cannot execute at the same time (mutual exclusion), then there exists a constrained dependence relationship between u and v.
Architectural Description Languages
Architectural description language (ADL) provides a semantics and syntax for describing a software architecture.
4.9 Architectural Mapping using Data Flow:
* Transform Mapping
Step 1. Review the fundamental system model
Step 2. Review and refine data flow diagrams for the software
Step 3. Determine whether the DFD has transform or transaction flow11 characteristics
Step 4. Isolate the transform center by specifying incoming and outgoing flow boundaries
Step 5. Perform “first-level factoring"
Step 6. Perform “second-level factoring"
Step 7. Refine the first-iteration architecture using design heuristics for improved software
quality
The objective of the preceding seven steps is to develop an architectural representation of software
See this figure below
Click here to view above image: LINK
* Refining the Architectural Design
Develop a representation of software that will meet all functional and performance requirements and merit acceptance based on design measures and heuristics
4.10 Components, 4.11 Designing Class-Based Components
* Large blocks of architecture are usually called Components.
* Component= a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.
* three views of a component
OO View
OO View
Traditional View / Structured View
Traditional View / Structured View
Process- related View
Choose components or design patterns from the catalog and use them to populate the architecture i.e., created with reusability
* Basic Design Principles:
The Open-Closed Principle (OCP): A module [component] should be open for extension but closed for modification.
The Liskov Substitution Principle (LSP): Subclasses should be substitutable for their base classes”
Dependency Inversion Principle (DIP): Depend on abstractions. Do not depend on concretions
The Interface Segregation Principle (ISP): Many client-specific interfaces are better than one general purpose interface
The Release Reuse Equivalency Principle (REP): The granule of reuse is the granule of release
The Common Closure Principle (CCP): Classes that change together belong together.
The Common Reuse Principle (CRP): Classes that aren’t reused together should not be grouped together
* Component-Level Design Guidelines
Components: Naming conventions should be established for components
Interfaces: Interfaces provide important information about communication and
Collaboration
Dependencies and Inheritance.
For improved readability, it is a good idea to model dependencies from left to right and inheritance from bottom (derived classes) to top (base classes)
* Cohesion
Cohesion = single-mindedness of a component.
OR
a component or class encapsulates only attributes and operations that
are closely related to one another and to the class or component itself.
#Functional. Exhibited primarily by operations
#Layer. Exhibited by packages, components, and classes
#Communicational All operations that access the same data are defined
within one class.
* Coupling
Coupling = qualitative measure of the degree to which classes are connected to
one another.
Content Coupling:
Component modifies data in another component (violates inf hiding)
Common Coupling:
Global variable used by multiple components
Control coupling. Occurs when operation A() invokes operation B() and passes a control flag to B.
Stamp coupling: Occurs when ClassB is declared as a type for an argument of an operation of ClassA.
Data coupling: Occurs when operations pass long strings of data arguments.
Routine call coupling: Occurs when one operation invokes another
Type use coupling: Occurs when component A uses a data type defined in component B .i.e., changes definition type
Inclusion or import coupling: Occurs when component A imports or includes a package or the content of component B.
External coupling: Occurs when a component communicates or collaborates with infrastructure components.
4.12 Conducting Component-Level Design
Step 1. Identify all design classes that correspond to the problem domain
Step 2. Identify all design classes that correspond to the infrastructure domain.
Step 3. Elaborate all design classes that are not acquired as reusable Components
Step 3a. Specify message details when classes or components collaborate.
Step 3b. Identify appropriate interfaces for each component
Step 3c. Elaborate attributes and define data types and data structures required to implement them.
Step 3d. Describe processing flow within each operation in detail
Step 4. Describe persistent data sources (databases and files) and identify the classes required to manage them.
Step 5. Develop and elaborate behavioral representations for a class or component.
Step 6. Elaborate deployment diagrams to provide additional implementation detail.
Step 7. Refactor every component-level design representation and always consider alternatives.
4.13 Component-Level Design for Web Apps
Content Design at the Component Level
A number of potential content components can be defined for the video surveillance
capability:
(1) the content objects that represent the space layout (the floor plan) with additional icons representing the location of sensors and video cameras,
(2) the collection of thumbnail video captures (each a separate data object), and
(3) the streaming video window for a specific camera. Each of these components can be separately named and manipulated as a package.
Functional Design at the Component Level
Modern Web applications deliver increasingly sophisticated processing functions that:
(1) perform localized processing to generate content and navigation capability in a dynamic fashion
(2) provide computation or data processing capability that is appropriate for the WebApp’s business domain
(3) provide sophisticated database query and access, or
(4) establish data interfaces with external corporate systems
Graphical Design Notation
A flowchart, like an activity diagram, is quite simple pictorially.
Tabular Design Notation
Decision Tables = contain Conditions followed by actions.
1. List all actions that can be associated with a specific procedure (or component).
2. List all conditions (or decisions made) during execution of the procedure.
3. Associate specific sets of conditions with specific actions, eliminating impossible combinations of conditions; alternatively, develop every possible permutation of conditions.
4. Define rules by indicating what actions occur for a set of conditions.
Program Design Language
Program Design Language
Program design language (PDL), also called structured English or pseudo code, incorporates the logical structure of a programming language with the free-form expressive ability of a natural language (e.g., English).
PDL provides an elaboration of the procedural design for an early version of an alarm management component i.e., Algorithm like.
4.15 Component-Based Development.
Component-based software engineering (CBSE) is a process that emphasizes the design and construction of computer-based systems using reusable software components.
Domain Engineering
The steps in the process are defined as:
1. Define the domain to be investigated.
2. Categorize the items extracted from the domain.
3. Collect a representative sample of applications in the domain.
4. Analyze each application in the sample and define analysis classes.
5. Develop a requirements model for the classes.
Component Qualification, Adaptation, and Composition
Component Qualification Component qualification ensures that a candidate component will perform the function required, will properly “fit” into the architectural
style
Component Adaptation
In an ideal setting, domain engineering creates a library
of components that can be easily integrated into an application architecture. The implication of “easy integration”
Component Composition
The component composition task assembles qualified, adapted, and engineered components to populate the architecture established for an application.
Analysis and Design for Reuse
key issues that form a basis for design for reuse:
Standard data The application domain should be investigated and standard global data structures (e.g., file structures or a complete database) should be
identified. All design components can then be characterized to make use of these standard data structures.
Standard interface protocols
Three levels of interface protocol should be established: the nature of intramodular interfaces, the design of external technical (nonhuman) interfaces, and the human-computer interface.
Program templates An architectural style is chosen and can serve as a template for the architectural design of a new software.
Classifying and Retrieving Components
* Classification enables you to find and retrieve candidate reusable components, but a reuse environment must exist to integrate these components effectively
* The reuse library is one element of a larger software repository
Google Sites
Report abuse