Your SlideShare is downloading. ×
0
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Sametinger's book - Chapters 11, 12, 13
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Sametinger's book - Chapters 11, 12, 13

511

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
511
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Software Engineering with Reusable Components RiSE’s Seminars Sametinger’s book :: Chapters 11, 12 and 13 Ednaldo Dilorenzo
  • 2. Summary <ul><li>Software Engineering (Chapter 11) </li></ul><ul><ul><li>Introduction </li></ul></ul><ul><ul><li>Software Management </li></ul></ul><ul><ul><li>Software Design </li></ul></ul><ul><ul><li>Software Implementation </li></ul></ul><ul><ul><li>Software Testing </li></ul></ul><ul><ul><li>Software Maintenance </li></ul></ul><ul><li>Software Process Models (Chapter 12) </li></ul><ul><ul><li>Waterfall Model </li></ul></ul><ul><ul><li>Exploratory Model </li></ul></ul><ul><ul><li>Prototyping Model </li></ul></ul><ul><ul><li>Spiral Model </li></ul></ul><ul><ul><li>Twin Life Cycle </li></ul></ul>
  • 3. Summary <ul><li>Domain Engineering </li></ul><ul><ul><li>Domain Analyses </li></ul></ul><ul><ul><li>Domain Analyses Activities </li></ul></ul><ul><ul><li>Domain Analyses Methods </li></ul></ul><ul><ul><li>Foda: Feature-Oritented Domain Analyses </li></ul></ul><ul><ul><li>Domain Implementation </li></ul></ul>
  • 4. Software Engineering
  • 5. Introduction <ul><li>Cost-effective production of high-quality system is the primary goal of software engineering; </li></ul><ul><li>Software reuse and components provide crucial contributions in this direction; </li></ul><ul><li>Large software projects are broken up into various project phases; </li></ul>Software Engineering :: Chapter 11
  • 6. Software Management <ul><li>Software projects tend to run over budget and behind schedule; </li></ul><ul><li>Software management has to plan a project; </li></ul><ul><li>It comprises the following major activities: </li></ul><ul><ul><li>Project planning </li></ul></ul><ul><ul><li>Project measuring </li></ul></ul><ul><ul><li>Project estimating </li></ul></ul><ul><ul><li>Project scheduling </li></ul></ul><ul><ul><li>Project controlling </li></ul></ul>Software Engineering :: Chapter 11
  • 7. Software Specification <ul><li>Software specifications serve as contracts between customers and manufacturers of software systems. </li></ul><ul><li>For complex systems, requirements analyses may be necessary. </li></ul><ul><li>A software specification should be complete. </li></ul><ul><li>Functional and nonfunctional requirements are among the most important parts of a specification. </li></ul><ul><li>Specifications should completely and consistently define requirements on components. </li></ul>Software Engineering :: Chapter 11
  • 8. Software Design <ul><li>Software Design is an iterative process and involves describing a component at different levels of abstraction. </li></ul><ul><li>Design includes various activities: </li></ul><ul><ul><li>Architectural design </li></ul></ul><ul><ul><li>Component or interface design </li></ul></ul><ul><ul><li>Data structure design </li></ul></ul><ul><ul><li>Algorithmic design </li></ul></ul>Software Engineering :: Chapter 11
  • 9. Software Design <ul><li>Top-down design is typical for components being built from scratch. </li></ul><ul><li>Botton-up design proceeds in the oposite direction. </li></ul><ul><li>Good designs are considered to have the following characteristics: </li></ul><ul><ul><li>Modularity </li></ul></ul><ul><ul><li>Coupling </li></ul></ul><ul><ul><li>Cohesion </li></ul></ul><ul><ul><li>Understandability, Adaptability </li></ul></ul>Software Engineering :: Chapter 11
  • 10. Software Design <ul><li>All these characteristics are related to each other. </li></ul><ul><li>Various categories of design methods exist. </li></ul><ul><li>Design methods and software reuse interact in two ways. </li></ul>Software Engineering :: Chapter 11
  • 11. Software Implementation <ul><li>Implementation is the process of transforming a design into an executable. </li></ul><ul><li>Ideally, the design of a component is independent of its implementation. </li></ul><ul><li>We refrain from dealing with implementation in greater detail. </li></ul>Software Engineering :: Chapter 11
  • 12. Software Testing <ul><li>The purpose of testing is to ascertain whether a component satisfies its requirements by discovering as many errors as possible. </li></ul><ul><li>Various kinds of tests include the following: </li></ul><ul><ul><li>Specification test </li></ul></ul><ul><ul><li>Component test </li></ul></ul><ul><ul><li>Integration test </li></ul></ul><ul><ul><li>Acceptance test </li></ul></ul>Software Engineering :: Chapter 11
  • 13. Software Testing <ul><li>Various testing methods and strategies include: </li></ul><ul><ul><li>Static/dynamic testing </li></ul></ul><ul><ul><li>Black-box/white-box testing </li></ul></ul><ul><ul><li>Top-down/botton-up testing </li></ul></ul><ul><li>With software reuse, software quality can be increased and testing efforts can be decreased. </li></ul>Software Engineering :: Chapter 11
  • 14. Software Maintenance <ul><li>Software maintenance is the modification of a software component after its first delivery. </li></ul><ul><li>Maintenance activities fall into the following categories: </li></ul><ul><ul><li>Adaptive maintenance </li></ul></ul><ul><ul><li>Corrective maintenance </li></ul></ul><ul><ul><li>Perfective maintenance </li></ul></ul><ul><ul><li>Preventive maintenance </li></ul></ul>Software Engineering :: Chapter 11
  • 15. Software Maintenance <ul><li>The cost of maintenance has been steadily increasing over the past decades. </li></ul><ul><li>Reuse can have a positive influence on maintenance costs when high-quality components are available and reused for the development of software systems. </li></ul>Software Engineering :: Chapter 11
  • 16. Waterfall Model <ul><li>According to the waterfall model, the software development process is divided in well-defined phases. </li></ul><ul><li>The waterfall life cycle comprises the following steps: </li></ul><ul><ul><li>Requirements analysis </li></ul></ul><ul><ul><li>Specification </li></ul></ul><ul><ul><li>Design </li></ul></ul><ul><ul><li>Implementation </li></ul></ul><ul><ul><li>Test </li></ul></ul><ul><ul><li>Operation and Maintenance </li></ul></ul>Software Process Models :: Chapter 12
  • 17. Waterfall Model <ul><li>Any step might uncover problems in a previous step and necessitate returning and partly or even completely redoing earlier work. </li></ul><ul><li>The waterfall model enforces a linear process, which implies that executable programs are available late in the process. </li></ul><ul><li>Despite its drawbacks, the classic software life cycle continues to provide structure for many software projects. </li></ul>Software Process Models :: Chapter 12
  • 18. Exploratory Model <ul><li>The classic software life cycle is not practical for many of today’s software systems. </li></ul><ul><li>In the exploratory model a working system is developed as quickly as possible. </li></ul><ul><li>Large, longevous software systems are usually not developed by using exploratory programming. </li></ul><ul><li>Exploratory software development involves repeatedly applying techniques. </li></ul>Software Process Models :: Chapter 12
  • 19. Exploratory Model <ul><li>Good when both customers and developers don’t know what they want. </li></ul><ul><li>The exploratory model delivers various operational but incomplete products. </li></ul><ul><li>Exploratory development challenge software engineers in that they create an open architecture. </li></ul>Software Process Models :: Chapter 12
  • 20. Prototyping Model <ul><li>Rapid prototyping has become popular for the development of software systems with complex user interfaces. </li></ul><ul><li>The purpose of the prototype is to enable customer and developer to agree on what the software system is supposed to do. </li></ul><ul><li>Prototypes are useful for software components as well, especially those with complex user interfaces. </li></ul>Software Process Models :: Chapter 12
  • 21. Spiral Model <ul><li>The key characteristics of this model are regular assessments of management risks and actions to counteract these risks. </li></ul><ul><li>Each cycle of spiral have the following steps: </li></ul><ul><ul><li>Specifying objectives; </li></ul></ul><ul><ul><li>List alternatives and their constraints; </li></ul></ul><ul><ul><li>Assessing each of the alternatives against each objective; </li></ul></ul><ul><li>The spiral model incorporates other process models. </li></ul>Software Process Models :: Chapter 12
  • 22. Twin Life Cycle <ul><li>Different organizational groups are involved in systematic reuse: </li></ul><ul><ul><li>Domain groups; </li></ul></ul><ul><ul><li>Component groups; </li></ul></ul><ul><ul><li>Application groups; </li></ul></ul><ul><li>Software process models and software reuse interact in two ways: </li></ul><ul><ul><li>Design with reuse; </li></ul></ul><ul><ul><li>Design for reuse; </li></ul></ul><ul><li>Provides only a rough overview, but it clearly demonstrates activities of groups. </li></ul>Software Process Models :: Chapter 12
  • 23. Domain Analyses <ul><li>Common objects and operations are likely to occur in multiple applications within a domain. </li></ul><ul><li>Domain analyses stresses the reusability of analyses and design, not code. </li></ul><ul><li>Domain-specific reuse is usually accomplished by separating domain engineering and application engineering. </li></ul>Domain Engineering :: Chapter 13
  • 24. Domain Analyses <ul><li>Information Sources </li></ul><ul><ul><li>Existing applications; </li></ul></ul><ul><ul><li>Domain experts; </li></ul></ul><ul><li>Products </li></ul><ul><ul><li>Domain definition; </li></ul></ul><ul><ul><li>Domain model; </li></ul></ul><ul><ul><li>Domain requirements model; </li></ul></ul><ul><ul><li>Architecture model; </li></ul></ul><ul><ul><li>Domain taxonomy; </li></ul></ul><ul><ul><li>Domain language; </li></ul></ul><ul><ul><li>Domain standards; </li></ul></ul><ul><ul><li>Reusable components; </li></ul></ul>Domain Engineering :: Chapter 13
  • 25. Domain Analyses <ul><li>In the context of domain analysis we can distinguish the following categories: </li></ul><ul><ul><li>General purpose; </li></ul></ul><ul><ul><li>Domain-specific components; </li></ul></ul><ul><ul><li>Product-specific components; </li></ul></ul><ul><li>Benefits </li></ul><ul><ul><li>Reuse of domain knowledge; </li></ul></ul><ul><ul><li>Reuse of components in a certain context; </li></ul></ul><ul><ul><li>Domain-specific model for classification; </li></ul></ul><ul><ul><li>Framework for tooling and systems synthesis from reusable components; </li></ul></ul><ul><ul><li>Large-grain reuse across products; </li></ul></ul><ul><ul><li>Identification of reusable software components; </li></ul></ul>Domain Engineering :: Chapter 13
  • 26. Domain Analysis Activities <ul><li>Activities in domain analysis have been described by various authors. </li></ul><ul><li>Arango has compared several domain analysis methods and extracted a common process with the following activities: </li></ul><ul><ul><li>Domain Definition and Preparation </li></ul></ul><ul><ul><li>Data Collection </li></ul></ul><ul><ul><li>Data Analysis and Classification </li></ul></ul><ul><ul><li>Evaluation </li></ul></ul>Domain Engineering :: Chapter 13
  • 27. Domain Definition and Preparation <ul><li>It is important that a domain be clearly defined and its boundaries be established; </li></ul><ul><li>After the definition of the domain, relevant data has to be identified and collected for the acquisition of domain knowledge; </li></ul>Domain Engineering :: Chapter 13
  • 28. Data Collection <ul><li>Different approaches for data collection can be used, e.g., reviews of literature, interviews of experts, analysis of applications. </li></ul><ul><li>In determining reusable components various levels can be chosen for analysis; </li></ul><ul><li>Different sources of information provide different types of information; </li></ul>Domain Engineering :: Chapter 13
  • 29. Data Analysis and Classification <ul><li>It is crucial to analyze similarities, variations and combinations of data. </li></ul><ul><li>The activities in this step are not entirely different from activities in developing a single software system. </li></ul><ul><li>Domain information is prepared by abstracting and generalizing functions, objects and their relationships. </li></ul>Domain Engineering :: Chapter 13
  • 30. Evaluation <ul><li>Besides using and refining models, it helpful to evaluate the domain; </li></ul><ul><li>Real application developments are the best evaluation and test of a domain; </li></ul>Domain Engineering :: Chapter 13
  • 31. Domain Analysis Methods <ul><li>Domain analysis methods provide some sort of systematic proceeding to do domain analyses; </li></ul><ul><li>Argo has presented, compared and evaluated eight domain analysis methods; </li></ul><ul><li>They are essentially similar, with the main differences in: </li></ul><ul><ul><li>Emphasis on certain data acquisition means over others; </li></ul></ul><ul><ul><li>Approach to modeling, e.g., functional vs. object-oriented techniques; </li></ul></ul><ul><ul><li>Overlapping subsets of notations; </li></ul></ul><ul><ul><li>Different groupings of activities with different names; </li></ul></ul><ul><ul><li>Same names with slightly different meanings; </li></ul></ul>Domain Engineering :: Chapter 13
  • 32. Foda: Feature-Oriented Domain Analysis <ul><li>It was developed at the Software Engineering Institute </li></ul><ul><li>Foda contains the basic phases: </li></ul><ul><ul><li>Context Analysis; </li></ul></ul><ul><ul><li>Domain Modeling; </li></ul></ul><ul><ul><li>Architecture Modeling; </li></ul></ul>Domain Engineering :: Chapter 13
  • 33. Context Analysis <ul><li>Define the scope of the domain and its relationships to other domain </li></ul><ul><ul><li>Context model; </li></ul></ul><ul><ul><li>Structure diagrams; </li></ul></ul><ul><ul><li>Data flow diagrams; </li></ul></ul>Domain Engineering :: Chapter 13
  • 34. Domain Modeling <ul><li>Analyze commonalties and differences of problems being addressed by applications in the domain </li></ul><ul><ul><li>Feature analysis; </li></ul></ul><ul><ul><li>Entity relationship modeling; </li></ul></ul><ul><ul><li>Functional analysis; </li></ul></ul>Domain Engineering :: Chapter 13
  • 35. Architecture Modeling <ul><li>Provide a software solution to problems defined during domain modeling. </li></ul><ul><li>The Foda architecture model is a high-level design of applications in the domain. </li></ul>Domain Engineering :: Chapter 13
  • 36. Domain Implementation <ul><li>Domain implementation means the use of the information collected in domain analysis to create reusable components and new systems. </li></ul>Domain Engineering :: Chapter 13

×