L8 - March 28, 2006copyright Thomas Pole 2003-2006, all rights reserved 1 Lecture 8: Software Asset Management and Text Ch. 5: Software Factories, (Review)

L8 - March 28, 2006 copyright Thomas Pole 2003-2006, all rights reserved

1

Lecture 8: Software Asset Management

and Text Ch. 5: Software Factories, (Review)

andCh 5: Models and Patterns


2

Agenda• Review: Mid Term Exam • Review: Software Factories • Lecture: Software Asset Management• Text: Chapter 6: “Models and Patterns”• Class Project

– Overview: We will employ a reuse driven process, but not a full software factory approach.

– Project Assignment #1:• Domain Definition and Discerning Family Members

• Exercise #2 Review• Q&A


3

Mid Term Exam Review

• Good work, you all did well– All A’s and B’s, mostly A’s

• Unusual for one of my classes, usually mostly B’s

– Don’t get overly optimistic, the final exam/project will require more work, and a deeper understanding to achieve the same grade.

• No review notes:– Answers reviewed in class discussion


4

Review: Software Factories are:

• That which produces a software product line, a set of similar software products produced from a set of common components, using tools to automate the customization of each member of the line.– Uses a software factory template to develop and

maintain a variant of the line. …– Which is based on a software factory schema, which

represents all the work products of a all the members of the product line, and the relationships among those work products.

• Schema grids bad, schema graphs good


5

Software Factory Schema as a Grid

• Each column: All the work products of a specific “concern” (e.g. data and actor definitions see pp 165 fig 5.4).

• Each row in the column is a level of abstraction for that “concern” (e.g. Biz entities, message schemas, database schemas and access strategy – moving from abstract to concrete)

• Schema as Grid Bad, hard to define “concerns”, can’t represent all realtionships among all work products (a.k.a. artifacts)


6

Software Factory Schema as Graph (or more properly network diagram)

• Can represent all relationships among all artifacts:– Different abstractions in one “concern”– Different artifacts in different “concerns”

• You can have multiple graphs to represent different clusters of artifacts.

• The software schema identifies all the artifacts that must be developed to produce ONE software product, one member of the product family or product line.


7

The Recipe pp 172• A software factory schema is a recipe for building

a family of software products.– Imagine a recipe that can make an kind of a cookie.– When building a schema, we must represent all the

possible cookies, and all the vairations that must be implemented to produce all those different cookies.

• When using a schema we are ONLY interested in building one product, one software system of the many members of the product line.– We configure a schema to build a specific product line

family member, we only want to build a chocolate chip cookie.


8

Review: Software Template

• A schema only describes the assets (the reusable components, customizable tools, etc.)

• A template includes the assets, the code, design patterns, metadata, etc. which can be loaded into the tools, to produce a specific family member of the product line the software factory produces.


9

Software Factory Summary

• Configuring a software factory schema customizes (to one family member) the description of the software factory.

• Configuring a template customizes the tools and other pieces of the development environment to build that family member.

• More, much more later.


10

L8: Software Asset Management• Successor to Software Reuse Library Management

Systems• Primary Vendors

– Logic Library• http://www.logiclibrary.com/logidex

– Flashline• www.flashline.com

• Manage the storage, access of, relationships among, and the metadata describing the use of and relationships among the reusable assets.

• More later on this subject.

http://www.logiclibrary.com/logidex





11

Break

• 15 minutes

• Next:– Ch 6: Models and Patterns– Class Project– Exercise #2 review– Questions?


12

Models, a few thoughts

• One man’s implementation is another man’s specification.– A programmer sees code as implementation,

the product, the result of the programmer’s effort.

– A compiler sees code as a specification, instructions on how to produce a product.

• One man’s model is another man’s reality.


13

SDLC as a Series of Models

• A requirements statement models the user’s real world.– Input: real world -> Model: requirements

• A design implements the solution to the problem represented by the requirements.– Input: requirements -> Model: High Level Design

• A system spec (interface, objects, etc.) implements the design.– Input HLDesign -> Model: Architectural Specification.


14

CH 6: Models and Patterns

• Patterns: Capture intent and map it to implementation.– Intent: What the engineer means to develop,

independent of the implementation technologies used to make that concrete implementation.

Patterns: Provides a strategy for solving a recurring problem (therefore, are a reuse based technique).


15

Pattern Language

• It is difficult to relate patterns to each other, therefore it is difficult to weave them into solutions to larger problems.

• A pattern language is a set of patterns and the relationships among the patterns; allowing that weaving of larger solutions to occur.


16

Models

• A model is an abstraction, a description of something which purposely leave out details that are not required for the job at hand, thus reducing the the complexity it would take to work with the thing itself.– Model Visualization -> UML– Models tell about a thing, they are not the thing,

therefore models can be considered metadata.


17

Models as Development Artifacts

• If the model contains that which can change (variations) among the family members of a product line.

• It there are tools which can be fed those variations.• Then a Software Factory can take a model of a

variant (family member) and generate the implementation of that product represented by the variant.


18

Class Project: Overview

• Produce a reuse driven software development infrastructure:– Process– Assets– Tools

• Model transformers (e.g. requirements to design)• Asset Managers• Asset assemblers

– Examples: Family Members


19

Class Project: Assignment #1

• Write the domain definition.– Used to determine what system are and are not members of the

product line.– Guides the scope of the reusable assets, tools and processes to be

built.

• Domain: Systems that allow an individual to track all the files, emails, hyperlinks, etc. according to how they will use them, how valuable they are, etc.

• Assignment: Using a basic into paragraph, as well as multiple variation points and variants; write th domain definition for lour project.


20

Ex. 2 ReviewReusable Asset Design

• We’ll review your solutions.


21

Questions?

• For next week:– Read the introduction through chapter 7,

“Programming with Models” for next week.– Email me your domain definitions no later then

9:00 PM Monday April 3, 2006.

L8 - March 28, 2006copyright Thomas Pole 2003-2006, all rights reserved 1 Lecture 8: Software Asset Management and Text Ch. 5: Software Factories, (Review)

Documents

software schema

software product line

software templatea schema

family of software products

software system

software factory template

software factory approach

software factories lecture