MEET PATEL
SER-516
SOFTWARE FACTORY AND SOFTWARE PRODUCT LINES
Software Factory
A software factory is a collection of assets that helps in developing software applications or components according to the specific user requirements through an assembly process. Software factory implements the traditional manufacturing principles to application development to mimic the benefits of manufacturing. Software Factory develop a product family whose members have variations but also share many common features. Software factories provide solutions to the family wide problems while also not disturbing the variations among the family members. A software factory systematically produces the members of a specific product family in the form of assets and then applies those assets for automatic development of the product family members, reducing cost and time to market and improving the quality of a software product[1].
Future of Software Factories
1) Assembly Development :70% of the application will be supplied by ready built, assembly developed components.
2) Software Supply chains :Supply chains would be required to satisfy the demands generated by the software factories.
3) Relationship Management :Customer Service Agreements will emerge documenting the post deployment service, maintenance, repairs based on the warranty.
4) Domain Specific Assets :Developers will not have to write large amount of code and develop application from scratch, they will use tools and write small amount of code to develop applications.
5) Mass Customization :When software industry will achieve value chain integration, software industry will eventually adopt mass customization.
6) Organizational Change :Development will not include writing-code, however it will be focused on assembling. More focus will be given on developing skills, incentives and process required to exploit changes.[1]
Creation of Software Factories
This era had Object Orientation as the basis of INNOVATION. Now, we need new technologies to make a forward jump in the field of Software Development. This is when Software Factory comes into the scene. Domain Specific Engineering and Software Product Line are moving forward in the field of two Object oriented technologies, Component-based Development and Model-driven Development. These 2 technologies are providing us a platform where we can correct our mistakes and apply our knowledge in innovative ways, basically in 3 axes.[1]
1) Abstraction
2) Granularity
3) Specificity
Model-Driven Development: A software Development methodology that focuses on a specific Domain Model and all the concepts related to a specific problem. Model-Driven Development leverages graphical models and pre-built components so that users can construct complex applications with ease and at the speed at which they can deploy the business applications. MDD uses the ideas and technologies that have object orientation. MDD promises to have platform specific compilers to produce multiple implementations from a single specification. MDD has two major concepts which are described in the next topic.[1][5]
1) Abstraction
2) Automation
Component-Based Development: A development methodology that accelerates the application development process with the help of reusable software components. With CBD, focus shifts from programming to composing and decomposing the software components. CBD attempts to minimize the dependencies by deploying the coarse-grained and independent software constructs using encapsulation. CBD focuses on 2 ideas
1) Interfaces – Distinction between a specification of component and its implementation.
2)Structure and Behavior of Application – Collaborations among the component based only on specifications and not implementation.[1][3]
A software Schema associated with the Domain Specific Languages is used to describe the specifications to develop a software product. A software template consisting of software schema, processes capturing the information from schema and using it, tools to automate that process is loaded into the tool known as Integrated Development Environment(IDE). This IDE is configured with software template for a product family and hence it becomes a factory for developing members of family.[1][3]
Abstraction
Abstraction is hiding the unnecessary details or characteristics while emphasizing the others to define a contract that separates the concerns of stakeholders. Raising the level of Abstraction reduces the complexity and brittleness of the software through encapsulation. The higher level of Abstraction the narrower their scope of application. Powerful Abstraction levels encapsulate a large amount of code to address Domain Specific applications. The current innovation curve shows the increasing abstraction in platform technology.[1]
Critical Innovations in Abstraction: CASE tools were exploiting the benefits of Abstraction were not able to Manage the complexities. CASE tools were not able to map the abstractions to the executable platform and hence created the layers of application code.[1]
Domain Specific Languages: Abstractions required a bridge to implementation. The solution to this problem is to increase the level of abstraction of the executable platform. This can be done in 2 ways.
1) Providing a software framework, that addresses a narrow domain and using abstractions in the model.
2)Providing a pattern language to implement abstraction instead of a framework.[1]
Transformations: Transformations are horizontal, vertical or oblique.
Vertical – refinement transformation which maps models from abstract DSL to code from general purpose programming language.
Horizontal – refactoring transformations which organize a specification by improving its design without changing the meaning.
Patterns are used in transformations. Transformation is mapping a pattern of objects in source model to pattern of objects in a target model.[1]
Granularity
Granularity refers to breaking down of large holistic tasks to smaller finely grained tasks. It refers to making things finer, more manageable pieces. It is a measure of size of a software construct. Granularity is used as a vehicle of Abstraction. Granularity has gradually increased from fine grained to higher coarse-grained services since the start of the era. Hash tables and exceptions represent the fine-grained classes, user interface controls represent the medium grained and business entities represent the coarse-grained components. Higher the granularity, more improved is the reuse of Abstraction because a coarse-grained component encapsulates more functionality, has very less dependencies and has independent unit of specification, design, implementation, testing, deployment, maintenance and enhancement.[1][4]
Critical Innovations in Granularity: In mid-nineties, component-based development techniques emerged but were not mature enough to support large scale components. They were not able to support a component marketplace. Then came the emerging web service technology. Web service technology succeeded. SOAP protocol and XML based extensions are available for large web applications. Web services use WSDL (Web service Definition Language) to define web services. WSDL is an XML file which specifies how it is invoked and what it returns. However, WSDL misses one concept of sequence interaction. A web service component must be familiar with message order and what happens when unexpected conditions arise.[1][4]
Specificity
Specificity is most important dimension to Software Factories. Specificity is defined as a scope of Abstraction. The value of Abstraction increases with the increase in specificity. Specific Abstractions can be used in less number of products but can contribute more to the development. General Abstractions can be used in more number of products but contribute less to development. Higher specificity allows more reuse of the components systematically.[1]
Relationship between Software factory and Software Product Line
A Software Factory is a Software Product Line which configures extensive tools, processes and content using a template which is produced on the basis of Schema to automate the development and maintenance of the software product by composing, decomposing, assembling, adapting and configuring framework-based software components.
In a software product line, a product line developer builds and uses the product line scope to build production assets. These assets are used by the product developer to build product family members.
In a software Factory, product line developer, builds and uses a software schema to build a software template. This template is loaded to the IDE (Integrated Development Environment). The product developer uses this IDE (Software Factory) to develop the product family members.
Software factory is built on the concepts of Software Product Line which exploits the product line to provide family wide solutions of the problems.[1]
Dynamic Software Product Lines
DSPL are capable of producing software which can adapt to changes in user needs and resource constraints.
Software Product line is a set of software systems that shares common features which satisfy a particular market and is developed with a common asset in a pre-documented way. Software Product lines has always helped in improving time-to-market, cost of production and quality of the software. Variability Management is the principle of SPL which separates the product lines into 3 parts – common components, parts common to some but not all and individual components and managing these components throughout the development.
However, in emerging domains and critical systems, software is becoming complex and requirements are changing. These modern systems are demanding a greater level of adaptability during the run time which resulted in emergence of DSPLs. DSPLs bind variation points at runtime when the software is launched and even when the software is operating, to adapt changes. SPLs bind variation points before deployment while DSPLs bind variation points before and after the deployment.[2]
DSPLs have the following properties:
1) Runtime binding and configuration
2) Addition of variation points
3) Dealing with sudden changes
4) Context and Situation Awareness
5) Self-adaptation
6) Automated decision making
7) Individual Environment instead of Market[2]
Ways to improve Abstraction in our Project
Abstraction can reduce complexity. It can also increase Testability and Maintainability. Hence, it is important to improve Abstraction. To improve abstraction, we need to divide a function which performs multiple tasks to functions which perform specific tasks. We need to implement interfaces to improve the abstraction. We need to segregate implementation from the interface to achieve abstraction by using some patterns like factory pattern.
Ways to improve Granularity in our Project
We need to make our project more coarse-grained if we want to improve the granularity. To make the project coarse-grained, we need to improve and increase the reusability of the components. More functionality can be encapsulated in a coarse-grained with lesser dependencies. We have to divide the functionalities as much as possible and make them independent to improve granularity.
Ways to improve Specificity in our Project
Specificity increases with the increase in Abstraction. Higher Abstraction narrows the problem domain and reusability. As Specificity increases with Abstraction, it promotes systematic reuse of the components. We can also improve the granularity by providing controller to each functionality in the project which in turn improves the specificity.
Improve |D| metric
In our project, we failed to achieve Abstraction. The value of Abstraction is almost zero or close to zero instead of 1. Hence our D value is negative. D value is also dependent on the instability. We have a quite good instability value, hence improving the abstraction will surely improve the |D| metric. |D| = |Instability + Abstraction -1|
Effort needed to improve the above factors
According to me, the effort required to improve Abstraction, Granularity, Specificity and D metric is 18 story points.
For Abstraction, 5 story points.
For Granularity, 5 story points.
For Specificity, 5 story points
For |D| metric, 3 story points.
Velocity
The velocity of our team is 62. We have 124 story points in the time frame of 2 sprints.
Velocity = Story points/ number of Sprints.
Sprints needed to improve the project
As you can see, we have 124 story points for 2 sprints, hence our velocity is 62 story points per sprint. For improving the project, we will only need 1 sprint as we have a total of 18 story points.
References
1. Greenfield, Jack, and Keith Short. "Software factories: assembling applications with patterns, models, frameworks and tools." Companion of the 18th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications. ACM, 2003.
2. Hallsteinsen, Svein, et al. "Dynamic software product lines." Computer 41.4 (2008).
3. https://www.techopedia.com/definition/31002/component-based-development-cbd
4. https://www.techopedia.com/definition/2209/granularity
5. https://www.techopedia.com/definition/16631/model-driven-development-mdd