First Edition, 2009
ISBN 978 81 907188 8 2
© All rights reserved.
Published by: Global Media 1819, Bhagirath Palace, Chandni Chowk, Delhi-110 006 Email:
[email protected]
Table of Contents 1. Introduction 2. Chapter1 - History of software engineering & software Engineering as a Profession 3. Chapter2 - Software design & Modeling languages for software design 4. Chapter3 - Software development & Software Testing 5. Chapter4 - Software development process, Computer-aided Software engineering Software quality
Introduction Software engineering
The new Airbus A380 uses a substantial amount of software to create a "paperless" cockpit. Software engineering successfully maps and plans the millions of lines of code comprising the plane's software Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software. The term software engineering first appeared in the 1968 NATO Software Engineering Conference and was meant to provoke thought regarding the current "software crisis" at the time. Since then, it has continued as a profession and field of study dedicated to creating software that is of higher quality, more affordable, maintainable, and quicker to build. Since the field is still relatively young compared to its sister fields of engineering, there is still much debate around what software engineering actually is, and if it conforms to the classical definition of engineering. It has grown organically out of the limitations of viewing software as just programming. "Software development" is a much used term in industry which is more generic and does not necessarily subsume the engineering paradigm. Although it is questionable what impact it has had on actual software development over the last more than 40 years, the field's future looks bright according to Money Magazine and Salary.com who rated "software engineering" as the best job in America in 2006.
Chapter-1 History of software engineering & software Engineering as a Profession History of software engineering History of computing Hardware before 1960 Hardware 1960s to present Hardware in Soviet Bloc countries
Artificial intelligence Computer science Operating systems Programming languages Software engineering
Graphical user interface Internet Personal computers
Laptops Video games World Wide Web
Timeline of computing
Timeline of computing 2400 BC–1949 1950–1979 1980–1989 1990-1999 2000— More timelines...
In the history of software engineering the software engineering has evolved steadily from its founding days in the 1940s until today in the 2000s. Applications have evolved continuously. The ongoing goal to improve technologies and practices, seeks to improve the productivity of practitioners and the quality of applications to users.
Overview There are a number of areas where the evolution of software engineering is notable:
Emergence as a profession: By the early 1980s, software engineering had already emerged as a bona fide profession, to stand beside computer science and traditional engineering. See also software engineering professionalism. Role of women: In the 1940s, 1950s, and 1960s, men often filled the more prestigious and better paying hardware engineering roles, but often delegated the writing of software to women. Grace Hopper, Jamie Fenton and many other unsung women filled many programming jobs during the first several decades of software engineering. Today, many fewer women work in software engineering than in other professions, a situation whose cause is not clearly identified and is often attributed to sexual discrimination, cyberculture or bias in education. Many academic and professional organizations are trying hard to solve this imbalance. Processes: Processes have become a big part of software engineering and are hailed for their potential to improve software and sharply criticized for their potential to constrict programmers.
Cost of hardware: The relative cost of software versus hardware has changed substantially over the last 50 years. When mainframes were expensive and required large support staffs, the few organizations buying them also had the resources to fund large, expensive custom software engineering projects. Computers are now much more numerous and much more powerful, which has several effects on software. The larger market can support large projects to create commercial off the shelf software, as done by companies such as Microsoft. The cheap machines allow each programmer to have a terminal capable of fairly rapid compilation. The programs in question can use techniques such as garbage collection, which make them easier and faster for the programmer to write. On the other hand, many fewer organizations are interested in employing programmers for large custom software projects, instead using commercial off the shelf software as much as possible.
The Pioneering Era The most important development was that new computers were coming out almost every year or two, rendering existing ones obsolete. Software people had to rewrite all their programs to run on these new machines. Programmers did not have computers on their desks and had to go to the "machine room". Jobs were run by signing up for machine time or by operational staff. Jobs were run by putting punched cards for input into the machine's card reader and waiting for results to come back on the printer. The field was so new that the idea of management by schedule was non-existent. Making predictions of a project's completion date was almost impossible. Computer hardware was application-specific. Scientific and business tasks needed different machines. Due to the need to frequently translate old software to meet the needs of new machines, highorder languages like FORTRAN, COBOL, and ALGOL were developed. Hardware vendors gave away systems software for free as hardware could not be sold without software. A few companies sold the service of building custom software but no software companies were selling packaged software. The notion of reuse flourished. As software was free, user organizations commonly gave it away. Groups like IBM's scientific user group SHARE offered catalogs of reusable components. Academia did not yet teach the principles of computer science. Modular programming and data abstraction were already being used in programming.
1945 to 1965: The origins The term software engineering first appeared in the late 1950s and early 1960s. Programmers have always known about civil, electrical, and computer engineering and debated what engineering might mean for software.
The NATO Science Committee sponsored two conferences on software engineering in 1968 and 1969, which gave the field its initial boost. Many believe these conferences marked the official start of the profession of software engineering.
1965 to 1985: The software crisis Software engineering was spurred by the so-called software crisis of the 1960s, 1970s, and 1980s, which identified many of the problems of software development. Many software projects ran over budget and schedule. Some projects caused property damage. A few projects caused loss of life. The software crisis was originally defined in terms of productivity, but evolved to emphasize quality. Some used the term software crisis to refer to their inability to hire enough qualified programmers.
Cost and Budget Overruns: The OS/360 operating system was a classic example. This decade-long project from the 1960s eventually produced one of the most complex software systems at the time. OS/360 was one of the first large (1000 programmers) software projects. Fred Brooks claims in The Mythical Man Month that he made a multi-million dollar mistake of not developing a coherent architecture before starting development. Property Damage: Software defects can cause property damage. Poor software security allows hackers to steal identities, costing time, money, and reputations. Life and Death: Software defects can kill. Some embedded systems used in radiotherapy machines failed so catastrophically that they administered lethal doses of radiation to patients. The most famous of these failures is the Therac 25 incident.
Peter G. Neumann has kept a contemporary list of software problems and disasters. The software crisis has been slowly fizzling out, because it is unrealistic to remain in crisis mode for more than 20 years. SEs are accepting that the problems of SE are truly difficult and only hard work over many decades can solve them.
1985 to 1989: No silver bullet For decades, solving the software crisis was paramount to researchers and companies producing software tools. Seemingly, they trumpeted every new technology and practice from the 1970s to the 1990s as a silver bullet to solve the software crisis. Tools, discipline, formal methods, process, and professionalism were touted as silver bullets:
Tools: Especially emphasized were tools: Structured programming, objectoriented programming, CASE tools, Ada, Java, documentation, standards, and Unified Modeling Language were touted as silver bullets. Discipline: Some pundits argued that the software crisis was due to the lack of discipline of programmers. Formal methods: Some believed that if formal engineering methodologies would be applied to software development, then production of software would become
as predictable an industry as other branches of engineering. They advocated proving all programs correct. Process: Many advocated the use of defined processes and methodologies like the Capability Maturity Model. Professionalism: This led to work on a code of ethics, licenses, and professionalism.
In 1986, Fred Brooks published the No Silver Bullet article, arguing that no individual technology or practice would ever make a 10-fold improvement in productivity within 10 years. Debate about silver bullets raged over the following decade. Advocates for Ada, components, and processes continued arguing for years that their favorite technology would be a silver bullet. Skeptics disagreed. Eventually, almost everyone accepted that no silver bullet would ever be found. Yet, claims about silver bullets pop up now and again, even today. Some interpret no silver bullet to mean that software engineering failed. The search for a single key to success never worked. All known technologies and practices have only made incremental improvements to productivity and quality. Yet, there are no silver bullets for any other profession, either. Others interpret no silver bullet as proof that software engineering has finally matured and recognized that projects succeed due to hard work. However, it could also be said that there are, in fact, a range of silver bullets today, including lightweight methodologies (see "Project management"), spreadsheet calculators, customized browsers, in-site search engines, database report generators, integrated design-test coding-editors with memory/differences/undo, and specialty shops that generate niche software, such as information websites, at a fraction of the cost of totally customized website development. Nevertheless, the field of software engineering appears too complex and diverse for a single "silver bullet" to improve most issues, and each issue accounts for only a small portion of all software problems.
1990 to 1999: Prominence of the Internet The rise of the Internet led to very rapid growth in the demand for international information display/e-mail systems on the World Wide Web. Programmers were required to handle illustrations, maps, photographs, and other images, plus simple animation, at a rate never before seen, with few well-known methods to optimize image display/storage (such as the use of thumbnail images). The growth of browser usage, running on the HTML language, changed the way in which information-display and retrieval was organized. The widespread network connections led to the growth and prevention of international computer viruses on MS Windows computers, and the vast proliferation of spam e-mail became a major design issue in email systems, flooding communication channels and requiring semi-automated pre-
screening. Keyword-search systems evolved into web-based search engines, and many software systems had to be re-designed, for international searching, depending on Search Engine Optimization (SEO) techniques. Human natural-language translation systems were needed to attempt to translate the information flow in multiple foreign languages, with many software systems being designed for multi-language usage, based on design concepts from human translators. Typical computer-user bases went from hundreds, or thousands of users, to, often, many-millions of international users.
2000 to Present: Lightweight Methodologies With the expanding demand for software in many smaller organizations, the need for inexpensive software solutions led to the growth of simpler, faster methodologies that developed running software, from requirements to deployment, quicker & easier. The use of rapid-prototyping evolved to entire lightweight methodologies, such as Extreme Programming (XP), which attempted to simplify many areas of software engineering, including requirements gathering and reliability testing for the growing, vast number of small software systems. Very large software systems still used heavily-documented methodologies, with many volumes in the documentation set; however, smaller systems had a simpler, faster alternative approach to managing the development and maintenance of software calculations and algorithms, information storage/retrieval and display.
Current trends in software engineering Software engineering is a young discipline, and is still developing. The directions in which software engineering is developing include: Aspects Aspects help software engineers deal with quality attributes by providing tools to add or remove boilerplate code from many areas in the source code. Aspects describe how all objects or functions should behave in particular circumstances. For example, aspects can add debugging, logging, or locking control into all objects of particular types. Researchers are currently working to understand how to use aspects to design general-purpose code. Related concepts include generative programming and templates. Agile Agile software development guides software development projects that evolve rapidly with changing expectations and competitive markets. Proponents of this method believe that heavy, document-driven processes (like TickIT, CMM and ISO 9000) are fading in importance. Some people believe that companies and agencies export many of the jobs that can be guided by heavy-weight processes. Related concepts include Extreme Programming, Scrum, and Lean software development. Experimental Experimental software engineering is a branch of software engineering interested in devising experiments on software, in collecting data from the experiments, and in devising laws and theories from this data. Proponents of this method advocate
that the nature of software is such that we can advance the knowledge on software through experiments only. Model-driven Model Driven Design develops textual and graphical models as primary design artifacts. Development tools are available that use model transformation and code generation to generate well-organized code fragments that serve as a basis for producing complete applications. Software Product Lines Software Product Lines is a systematic way to produce families of software systems, instead of creating a succession of completely individual products. This method emphasizes extensive, systematic, formal code reuse, to try to industrialize the software development process. The Future of Software Engineering conference (FOSE), held at ICSE 2000, documented the state of the art of SE in 2000 and listed many problems to be solved over the next decade. The FOSE tracks at the ICSE 2000 and the ICSE 2007 conferences also help identify the state of the art in software engineering.
Software engineering today The profession is trying to define its boundary and content. The Software Engineering Body of Knowledge SWEBOK has been tabled as an ISO standard during 2006 (ISO/IEC TR 19759). In 2006, Money Magazine and Salary.com rated software engineering as the best job in America in terms of growth, pay, stress levels, flexibility in hours and working environment, creativity, and how easy it is to enter and advance in the field.
Profession Software engineer A software engineer is a person who applies the principles of software engineering to the design, development, testing, and evaluation of the software and systems that make computers or anything containing software, such as chips, work.
Overview Prior to the mid-1990s, most software practitioners called themselves programmers or developers, regardless of their actual jobs. Many people prefer to call themselves
software developer and programmer, because most widely agree what these terms mean, while software engineer is still being debated. The term programmer has often been used as a pejorative term to refer to those without the tools, skills, education, or ethics to write good quality software. In response, many practitioners called themselves software engineers to escape the stigma attached to the word programmer. In many companies, the titles programmer and software developer were changed to software engineer, for many categories of programmers. These terms cause confusion, because some denied any differences (arguing that everyone does essentially the same thing with software) while others use the terms to create a difference (because the terms mean completely different jobs).
A state of the art In 2004, Keith Chapple U. S. Bureau of Labor Statistics counted 760,840 software engineers holding jobs in the U.S.; in the same time period there were some 1.4 million practitioners employed in the U.S. in all other engineering disciplines combined., Table software engineer is used very liberally in the corporate world. Very few of the practicing software engineers actually hold Engineering degrees from accredited universities. In fact, according to the Association for Computing Machinery, "most people who now function in the U.S. as serious software engineers have degrees in computer science, not in software engineering". See also Debates within software engineering and Controversies over the term Engineer.
Regulatory classification The U.S. Bureau of Labor Statistics classifies computer software engineers as a subcategory of "computer specialists", along with occupations such as computer scientist, programmer, and network administrator. The BLS classifies all other engineering disciplines, including computer hardware engineers, as "engineers". The U.K. has seen the alignment of the Information Technology Professional and the Engineering Professionals. Software engineering in Canada has seen some contests in the courts over the use of the title "Software Engineer" The Canadian Council of Professional Engineers (C.C.P.E. or "Engineers Canada") will not grant a "Professional Engineer" status/license to anyone who has not completed a recognized academic engineering program. Engineers qualified outside Canada are similarly unable to obtain a "Professional Engineer" license. Since 2001, the Canadian Engineering Accreditation Board has accredited several university programs in software engineering, allowing graduates to apply for a professional engineering licence once the other prerequisites are obtained, although this does nothing to help IT professionals using the title with degrees in other fields (such as computer science).
Some of the United States of America regulate the use of terms such as "computer engineer" and even "software engineer". These states include at least Texas and Florida. Texas even goes so far as to ban anyone from writing any real-time code without an engineering license.
Education About half of all practitioners today have computer science degrees. A small, but growing, number of practitioners have software engineering degrees. In 1987 Imperial College London introduced the first three year software engineering Bachelor's degree in the UK and the world, in the following year the University of Sheffield established a similar programme. In 1996, Rochester Institute of Technology established the first software engineering Bachelor's degree program in the United States, however, it did not obtain ABET until 2003, the same time as Clarkson University, Milwaukee School of Engineering and Mississippi State University. Since then, software engineering undergraduate degrees have been established at many universities. A standard international curriculum for undergraduate software engineering degrees was recently defined by the CCSE. As of 2004, in the U.S., about 50 universities offer software engineering degrees, which teach both computer science and engineering principles and practices. The first software engineering Master's degree was established at Seattle University in 1979. Since then graduate software engineering degrees have been made available from many more universities. Likewise in Canada, the Canadian Engineering Accreditation Board (CEAB) of the Canadian Council of Professional Engineers has recognized several software engineering programs. In 1998, the US Naval Postgraduate School (NPS) established the first doctorate program in Software Engineering in the world. Additionally, many online advanced degrees in Software Engineering have appeared such as the Master of Science in Software Engineering (MSE) degree offered through the Computer Science and Engineering Department at California State University, Fullerton. Steve McConnell opines that because most universities teach computer science rather than software engineering, there is a shortage of true software engineers. ETS University and UQAM were mandated by IEEE to develop the SoftWare Engineering BOdy of Knowledge SWEBOK, which has become an ISO standard describing the body of knowledge covered by a software engineer.
Other degrees In business, some software engineering practitioners have MIS degrees. In embedded systems, some have electrical or computer engineering degrees, because embedded software often requires a detailed understanding of hardware. In medical software, practitioners may have medical informatics, general medical, or biology degrees.
Some practitioners have mathematics, science, engineering, or technology degrees. Some have philosophy (logic in particular) or other non-technical degrees. And, others have no degrees. For instance, Barry Boehm earned degrees in mathematics.
Profession Employment Most software engineers work as employees or contractors. Software engineers work with businesses, government agencies (civilian or military), and non-profit organizations. Some software engineers work for themselves as freelancers. Some organizations have specialists to perform each of the tasks in the software development process. Other organizations required software engineers to do many or all of them. In large projects, people may specialize in only one role. In small projects, people may fill several or all roles at the same time. Specializations include: in industry (analysts, architects, developers, testers, technical support, managers) and in academia (educators, researchers). There is considerable debate over the future employment prospects for Software Engineers and other IT Professionals. For example, an online futures market called the Future of IT Jobs in America attempts to answer whether there will be more IT jobs, including software engineers, in 2012 than there were in 2002.
Certification Professional certification of software engineers is a contentious issue. Some see it as a tool to improve professional practice. Most successful certification programs in the software industry are oriented toward specific technologies, and are managed by the vendors of these technologies. These certification programs are tailored to the institutions that would employ people who use these technologies. The ACM had a professional certification program in the early 1980s, which was discontinued due to lack of interest. . As of 2006, the IEEE had certified over 575 software professionals. In Canada the Canadian Information Processing Society has developed a legally recognized professional certification called Information Systems Professional (ISP).
Impact of globalization Many students in the developed world have avoided degrees related to software engineering because of the fear of offshore outsourcing (importing software products or services from other countries) and of being displaced by foreign visa workers. Although government statistics do not currently show a threat to software engineering itself; a
related career, computer programming does appear to have been affected. Often one is expected to start out as a computer programmer before being promoted to software engineer. Thus, the career path to software engineering may be rough, especially during recessions. Some career counselors suggest a student also focus on "people skills" and business skills rather than purely technical skills because such "soft skills" are allegedly more difficult to offshore. It is the quasi-management aspects of software engineering that appear to be what has kept it from being impacted by globalization.
Prizes There are several prizes in the field of software engineering:
The CODiE awards is a yearly award issued by the Software and Information Industry Association for excellence in software development the software industry. Jolt Awards are awards in the software industry. Stevens Award is a software engineering award given in memory of Wayne Stevens.
Debates within software engineering Debates within software engineering
Controversies over the term Engineer Controversies over the term Engineer Some people believe that software engineering implies a certain level of academic training, professional discipline, and adherence to formal processes that often are not applied in cases of software development. A common analogy is that working in construction does not make one a civil engineer, and so writing code does not make one a software engineer. It is disputed by some - in particular by the Canadian Professional Engineers Ontario (PEO) body, that the field is mature enough to warrant the title "engineering". The PEO's position was that "software engineering" was not an appropriate name for the field since those who practiced in the field and called themselves "software engineers" were not properly licensed professional engineers, and that they should therefore not be allowed to use the name.
The status of software engineering The word engineering within the term software engineering causes a lot of confusion.
The wrangling over the status of software engineering (between traditional engineers and computer scientists) can be interpreted as a fight over control of the word engineering. Traditional engineers question whether software engineers can legally use the term. Traditional engineers (especially civil engineers and the NSPE) claim that they have special rights over the term engineering, and for anyone else to use it requires their approval. In the mid-1990s, the NSPE sued to prevent anyone from using the job title software engineering. The NSPE won their lawsuit in 48 states. However, SE practitioners, educators, and researchers ignored the lawsuits and called themselves software engineers anyway. The U.S. Bureau of Labor Statistics uses the term software engineer, too. The term engineering is much older than any regulatory body, so many believe that traditional engineers have few rights to control the term. As things stand at 2007, however, even the NSPE appears to have softened its stance towards software engineering and following the heels of several overseas precedents, is investigating a possibility of licensing software engineers in consultation with IEEE, NCEES and other groups "for the protection of the public health safety and welfare" . In Canada, the use of the words 'engineer' and 'engineering' are controlled in each province by self-regulating professional engineering organizations, often aligned with geologists and geophysicists, and tasked with enforcement of the governing legislation. The intent is that any individual holding themselves out as an engineer (or geologist or geophysicist) has been verified to have been educated to a certain accredited level, and their professional practice is subject to a code of ethics and peer scrutiny. This system was originally designed for the practise of engineering where public safety is a concern, but extends to other branches of engineering as well, including electronics and software. In New Zealand, IPENZ, the professional engineering organization entrusted by the New Zealand government with legal power to license and regulate chartered engineers (CPEng), recognizes software engineering as a legitimate branch of professional engineering and accepts application of software engineers to obtain chartered status provided he or she has a tertiary degree of approved subjects. Software Engineering is included but Computer Science is normally not.
Employment In 2004, the U. S. Bureau of Labor Statistics counted 760,840 software engineers holding jobs in the U.S.; in the same time period there were some 1.4 million practitioners employed in the U.S. in all other engineering disciplines combined. Due to its relative newness as a field of study, formal education in software engineering is often taught as part of a computer science curriculum, and as a result most software engineers hold computer science degrees. Most software engineers work as employees or contractors. Software engineers work with businesses, government agencies (civilian or military), and non-profit organizations. Some software engineers work for themselves as freelancers. Some organizations have specialists to perform each of the tasks in the software development process. Other
organizations require software engineers to do many or all of them. In large projects, people may specialize in only one role. In small projects, people may fill several or all roles at the same time. Specializations include: in industry (analysts, architects, developers, testers, technical support, managers) and in academia (educators, researchers). There is considerable debate over the future employment prospects for software engineers and other IT professionals. For example, an online futures market called the "ITJOBS Future of IT Jobs in America" attempts to answer whether there will be more IT jobs, including software engineers, in 2012 than there were in 2002.
Certification Professional certification of software engineers is a contentious issue. Some see it as a tool to improve professional practice; "The only purpose of licensing software engineers is to protect the public". The ACM had a professional certification program in the early 1980s, which was discontinued due to lack of interest. The ACM examined the possibility of professional certification of software engineers in the late 1990s, but eventually decided that such certification was inappropriate for the professional industrial practice of software engineering. As of 2006, the IEEE had certified over 575 software professionals. In the U.K. the British Computer Society has developed a legally recognized professional certification called Chartered IT Professional (CITP), available to fully qualified Members (MBCS). In Canada the Canadian Information Processing Society has developed a legally recognized professional certification called Information Systems Professional (ISP). The Software Engineering Institute offers certification on specific topic such as Security, Process improvement and Software architecture. Most certification programs in the IT industry are oriented toward specific technologies, and are managed by the vendors of these technologies. These certification programs are tailored to the institutions that would employ people who use these technologies.
Impact of globalization Many students in the developed world have avoided degrees related to software engineering because of the fear of offshore outsourcing (importing software products or services from other countries) and of being displaced by foreign visa workers. Although government statistics do not currently show a threat to software engineering itself; a related career, computer programming does appear to have been affected. Often one is expected to start out as a computer programmer before being promoted to software engineer. Thus, the career path to software engineering may be rough, especially during recessions. Some career counselors suggest a student also focus on "people skills" and business skills rather than purely technical skills because such "soft skills" are allegedly more difficult to
offshore. It is the quasi-management aspects of software engineering that appear to be what has kept it from being impacted by globalization.
Education A knowledge of programming is the main pre-requisite to becoming a software engineer, but it is not sufficient. Many software engineers have degrees in Computer Science due to the lack of software engineering programs in higher education. However, this has started to change with the introduction of new software engineering degrees, especially in postgraduate education. A standard international curriculum for undergraduate software engineering degrees was defined by the CCSE. Steve McConnell opines that because most universities teach computer science rather than software engineering, there is a shortage of true software engineers. In 2004 the IEEE Computer Society produced the SWEBOK, which has become an ISO standard describing the body of knowledge covered by a software engineer. The European Commission within the Erasmus Mundus Programme offers a European master degree called European Master on Software Engineering for students from Europe and also outside Europe. This is a joint program (double degree) involving 4 universities in Europe.
Chapter-2 Software design & Modeling languages
for software design Software design Software development process Activities and steps Requirements · Specification Architecture · Design Implementation · Testing Deployment · Maintenance Models Agile · Cleanroom · DSDM Iterative · RAD · RUP · Spiral Waterfall · XP · Scrum · Lean V-Model · FDD Supporting disciplines Configuration management Documentation Quality assurance (SQA) Project management
User experience design Tools Compiler · Debugger · Profiler GUI designer Integrated development environment
Software design is a process of problem-solving and planning for a software solution. After the purpose and specifications of software are determined, software developers will design or employ designers to develop a plan for a solution. It includes low-level component and algorithm implementation issues as well as the architectural view.
Overview The software requirements analysis (SRA) step of a software development process yields specifications that are used in software engineering. If the software is "semiautomated" or user centered, software design may involve user experience design yielding a story board to help determine those specifications. If the software is completely automated (meaning no user or user interface), a software design may be as simple as a flow chart or text describing a planned sequence of events. There are also semi-standard methods like Unified Modeling Language and Fundamental modeling concepts. In either case some documentation of the plan is usually the product of the design. A software design may be platform-independent or platform-specific, depending on the availability of the technology called for by the design.
Software design topics Design Concepts The design concepts provide the software designer with a foundation from which more sophisticated methods can be applied. A set of fundamental design concepts has evolved. They are:
1.Abstraction - Abstraction is the process or result of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose.
2.Refinement - It is the process of elaboration. A hierarchy is developed by decomposing a macroscopic statement of function in a stepwise fashion until programming language statements are reached. In each step, one or several instructions of a given program are decomposed into more detailed instructions. Abstraction and Refinement are complementary concepts. 3.Modularity - Software architecture is divided into components called modules. 4.Software Architecture - It refers to the overall structure of the software and the ways in which that structure provides conceptual integrity for a system. A software architecture is the development work product that gives the highest return on investment with respect to quality, schedule and cost. 5.Control Hierarchy - A program structure that represent the organization of a program components and implies a hierarchy of control. 6.Structural Partitioning - The program structure can be divided both horizontally and vertically. Horizontal partitions define separate branches of modular hierarchy for each major program function. Vertical partitioning suggests that control and work should be distributed top down in the program structure. 7.Data Structure - It is a representation of the logical relationship among individual elements of data. 8.Software Procedure - It focuses on the processing of each modules individually 9.Information Hiding - Modules should be specified and designed so that information contained within a module is inaccessible to other modules that have no need for such information.
Design considerations There are many aspects to consider in the design of a piece of software. The importance of each should reflect the goals the software is trying to achieve. Some of these aspects are:
Compatibility - The software is able to operate with other products that are designed for interoperability with another product. For example, a piece of software may be backward-compatible with an older version of itself. Extensibility - New capabilities can be added to the software without major changes to the underlying architecture. Fault-tolerance - The software is resistant to and able to recover from component failure. Maintainability - The software can be restored to a specified condition within a specified period of time. For example, antivirus software may include the ability to periodically receive virus definition updates in order to maintain the software's effectiveness. Modularity - the resulting software comprises well defined, independent components. That leads to better maintainability. The components could be then implemented and tested in isolation before being integrated to form a desired software system. This allows division of work in a software development project. Packaging - Printed material such as the box and manuals should match the style designated for the target market and should enhance usability. All compatibility
information should be visible on the outside of the package. All components required for use should be included in the package or specified as a requirement on the outside of the package. Reliability - The software is able to perform a required function under stated conditions for a specified period of time. Reusability - the modular components designed should capture the essence of the functionality expected out of them and no more or less. This single-minded purpose renders the components reusable wherever there are similar needs in other designs. Robustness - The software is able to operate under stress or tolerate unpredictable or invalid input. For example, it can be designed with a resilience to low memory conditions. Security - The software is able to withstand hostile acts and influences. Usability - The software user interface must be intuitive (and often aesthetically pleasing) to its target user/audience. Default values for the parameters must be chosen so that they are a good choice for the majority of the users. In many cases, online help should be included and also carefully designed.
Modeling language A modeling language is any artificial language that can be used to express information or knowledge or systems in a structure that is defined by a consistent set of rules. The rules are used for interpretation of the meaning of components in the structure. A modeling language can be graphical or textual. Examples of graphical modelling languages for software design are:
Business Process Modeling Notation (BPMN, and the XML form BPML) is an example of a Process Modeling language. EXPRESS and EXPRESS-G (ISO 10303-11) is an international standard generalpurpose data modeling language. Extended Enterprise Modeling Language (EEML) is commonly used for business process modeling across a number of layers. Flowchart is a schematic representation of an algorithm or a stepwise process, Fundamental Modeling Concepts (FMC) modeling language for softwareintensive systems. IDEF is a family of modeling languages, the most notable of which include IDEF0 for functional modeling, IDEF1X for information modeling, and IDEF5 for modeling ontologies. Jackson Structured Programming (JSP) is a method for structured programming based on correspondences between data stream structure and program structure LePUS3 is an object-oriented visual Design Description Language and a formal specification language that is suitable primarily for modelling large objectoriented (Java, C++, C#) programs and design patterns.
Unified Modeling Language (UML) is a general modeling language to describe software both structurally and behaviorally. It has a graphical notation and allow for extension with a Profile (UML). Alloy (specification language) is a general purpose specification language for expressing complex structural constraints and behavior in a software system. It provides a concise language based on first-order relational logic.
Business Process Modeling Notation
Example of a Business Process Modelling Notation of a process with a normal flow. Business Process Modelling Notation (BPMN) is a graphical representation for specifying business processes in a workflow. BPMN was developed by Business Process Management Initiative (BPMI), and is currently maintained by the Object Management Group since the two organizations merged in 2005. As of January 2009, the current version of BPMN is 1.2, with a major revision process for BPMN 2.0 in progress.
Overview The Business Process Modeling Notation (BPMN) is a standard for business process modeling, and provides a graphical notation for specifying business processes in a Business Process Diagram (BPD), based on a flowcharting technnique very similar to activity diagrams from Unified Modeling Language (UML). The objective of BPMN is to support business process management for both technical users and business users by providing a notation that is intuitive to business users yet able to represent complex process semantics. The BPMN specification also provides a mapping between the
graphics of the notation to the underlying constructs of execution languages, particularly Business Process Execution Language. The primary goal of BPMN is to provide a standard notation that is readily understandable by all business stakeholders. These business stakeholders include the business analysts who create and refine the processes, the technical developers responsible for implementing the processes, and the business managers who monitor and manage the processes. Consequently, BPMN is intended to serve as common language to bridge the communication gap that frequently occurs between business process design and implementation. Currently there are several competing standards for business process modeling languages used by modeling tools and processes. Widespread adoption of the BPMN will help unify the expression of basic business process concepts (e.g., public and private processes, choreographies), as well as advanced process concepts (e.g., exception handling, transaction compensation).
BPMN topics Scope BPMN will be constrained to support only the concepts of modeling that are applicable to business processes. This means that other types of modeling done by organizations for non-business purposes will be out of scope for BPMN. For example, the modeling of the following will not be a part of BPMN:
Organizational structures Functional breakdowns Data models
In addition, while BPMN will show the flow of data (messages), and the association of data artifacts to activities, it is not a data flow diagram.
Elements The modeling in BPMN is made by simple diagrams with a small set of graphical elements. It should make it easy for business users as well as developers to understand the flow and the process. The four basic categories of elements are as follows: Flow Objects Events, Activities, Gateways Connecting Objects Sequence Flow, Message Flow, Association Swimlanes Pool, Lane Artifacts (Artefacts)
Data Object, Group, Annotation These four categories of elements give us the opportunity to make a simple business process diagram (BPD). It is also allowed in BPD to make your own type of a Flow Object or an Artifact to make the diagram more understandable.
Flow objects and connecting objects
Event
Activity
Gateway
Connections
Flow objects are the main describing elements within BPMN, and consist of three core elements (Events, Activities, and Gateways): Event An Event is represented with a circle and denotes something that happens (rather than Activities which are something that is done). Icons within the circle denote the type of event (e.g. envelope for message, clock for time). Events are also classified as Catching (as in, they might catch an incoming message to Start the process) or Throwing (as in, they might throw a message at the End of the process). Start event Acts as a trigger for the process; indicated by a single narrow border; and can only be Catch, so is shown with an open (outline) icon. End event Represents the result of a process; indicated by a single thick or bold border; and can only Throw, so is shown with a solid icon. Intermediate event Represents something that happens between the start and end events; is indicated by a tramline border; and can Throw or Catch (using solid or open icons as appropriate) - for example, a task could flow to an event that throws a message across to another pool and a subsequent event waits to catch the response before continuing. Activity An Activity is represented with a rounded-corner rectangle and describes the kind of work which must be done. Task A task represents a single unit of work that is not or cannot be broken down to a further level of business process detail without diagramming the steps in a procedure (not the purpose of BPMN) Sub-process Used to hide or reveal additional levels of business process detail - when collapsed a sub-process is indicated by a plus sign against the bottom line of the
rectangle; when expanded the rounded rectangle expands to show all flow objects, connecting objects, and artefacts. Has its own self-contained start and end events, and sequence flows from the parent process must not cross the boundary. Transaction A form of sub-process in which all contained activities must be treated as a whole, i.e., they must all be completed to meet an objective, and if any one of them fails they must all be compensated (undone). Transactions are differentiated from expanded sub-processes by being surrounded by a tramline border. Gateway A Gateway is represented with a diamond shape and will determine forking and merging of paths depending on the conditions expressed. Flow objects are connected to each other using Connecting objects, which consist of three types (Sequences, Messages, and Associations): Sequence Flow A Sequence Flow is represented with a solid line and arrowhead and shows in which order the activities will be performed. The sequence flow may be also have a symbol at its start, a small diamond indicates one of a number of conditional flows from an activity while a diagonal slash indicates the default flow from a decision or activity with conditional flows. Message Flow A Message Flow is represented with a dashed line, an open circle at the start, and an open arrowhead at the end. It tells us what messages flow across organisational boundaries (i.e., between pools). A message flow can never be used to connect activities or events within the same pool. Association An Association is represented with a dotted line. It is used to associate an Artifact or text to a Flow Object, and can indicate some directionality using an open arrowhead (toward the artifact to represent a result, from the artifact to represent an input, and both to indicate it is read and updated). No directionality would be used when the Artifact or text is associated with a sequence or message flow (as that flow already shows the direction).
Swimlanes and artifacts
Annotation Swimlanes
Data objects
Groups
Swim lanes are a visual mechanism of organising and categorising activities, based on cross functional flowcharting, and in BPMN consist of two types: Pool Represents major participants in a process, typically separating different organisations. A pool contains one or more lanes (like a real swimming pool). A pool can be open (i.e., showing internal detail) when it is depicted as a large rectangle showing one or more lanes, or collapsed (i.e., hiding internal detail) when it is depicted as an empty rectangle stretching the width or height of the diagram. Lane Used to organise and categorise activities within a pool according to function or role, and depicted as a rectangle stretching the width or height of the pool. A lane contains the Flow Objects, Connecting Objects and Artifacts. Artifacts allow developers to bring some more information into the model/diagram. In this way the model/diagram becomes more readable. There are three pre-defined Artifacts and they are: Data Objects Data Objects show the reader which data is required or produced in an activity. Group A Group is represented with a rounded-corner rectangle and dashed lines. The Group is used to group different activities but does not affect the flow in the diagram. Annotation An Annotation is used to give the reader of the model/diagram an understandable impression.
Types of Business Process Diagram
A Process with Normal FlowDiscussion Cycle E-Mail Voting ProcessCollect Votes Within and between these three BPMN sub-models, many types of Diagrams can be created. The following are the types of business processes that can be modeled with BPMN (those with asterisks may not map to an executable language):
High-level private process activities (not functional breakdown)*
Detailed private business process As-is or old business process* To-be or new business process Detailed private business process with interactions to one or more external entities (or “Black Box” processes) Two or more detailed private business processes interacting Detailed private business process relationship to Abstract Process Detailed private business process relationship to Collaboration Process Two or more Abstract Processes* Abstract Process relationship to Collaboration Process* Collaboration Process only (e.g., ebXML BPSS or RosettaNet)* Two or more detailed private business processes interacting through their Abstract Processes Two or more detailed private business processes interacting through a Collaboration Process Two or more detailed private business processes interacting through their Abstract Processes and a Collaboration Process
BPMN is designed to allow all the above types of Diagrams. However, it should be cautioned that if too many types of sub-models are combined, such as three or more private processes with message flow between each of them, then the Diagram may become too hard for someone to understand. Thus, we recommend that the modeler pick a focused purpose for the BPD, such as a private process, or a collaboration process.
BPMN 2.0 The Business Process Model and Notation is the name of the working proposal for BPMN 2.0 The vision of BPMN 2.0 is to have one single specification for a new Business Process Model and Notation that defines the notation, metamodel and interchange format but with a modified name that still preserves the "BPMN" brand. The proposed features include
Aligning BPMN with the business process definition meta model BPDM to form a single consistent language Enabling the exchange of business process models and their diagram layouts among process modeling tools to preserve semantic integrity Expand BPMN to allow model orchestrations and choreographies as stand-alone or integrated models Support the display and interchange of different perspectives on a model that allow a user to focus on specific concerns Serialize BPMN and provide XML schemes for model transformation and to extend BPMN towards business modeling and executive decision support.
A beta version of the specification is expected to be released in September, 2009, with the final release scheduled for June, 2010.
Uses of BPMN Business process modeling is used to communicate a wide variety of information to a wide variety of audiences. BPMN is designed to cover this wide range of usage and allows modeling of end-to-end business processes to allow the viewer of the Diagram to be able to easily differentiate between sections of a BPMN Diagram. There are three basic types of sub-models within an end-to-end BPMN model: Private (internal) business processes, Abstract (public) processes, and Collaboration (global) processes: Private (internal) business processes Private business processes are those internal to a specific organization and are the type of processes that have been generally called workflow or BPM processes. If swim lanes are used then a private business process will be contained within a single Pool. The Sequence Flow of the Process is therefore contained within the Pool and cannot cross the boundaries of the Pool. Message Flow can cross the Pool boundary to show the interactions that exist between separate private business processes. Abstract (public) processes This represents the interactions between a private business process and another process or participant. Only those activities that communicate outside the private business process are included in the abstract process. All other “internal” activities of the private business process are not shown in the abstract process. Thus, the abstract process shows to the outside world the sequence of messages that are required to interact with that business process. Abstract processes are contained within a Pool and can be modeled separately or within a larger BPMN Diagram to show the Message Flow between the abstract process activities and other entities. If the abstract process is in the same Diagram as its corresponding private business process, then the activities that are common to both processes can be associated. Collaboration (global) processes A collaboration process depicts the interactions between two or more business entities. These interactions are defined as a sequence of activities that represent the message exchange patterns between the entities involved. Collaboration processes may be contained within a Pool and the different participant business interactions are shown as Lanes within the Pool. In this situation, each Lane would represent two participants and a direction of travel between them. They may also be shown as two or more Abstract Processes interacting through Message Flow (as described in the previous section). These processes can be modeled separately or within a larger BPMN Diagram to show the Associations between the collaboration process activities and other entities. If the collaboration process is in the same Diagram as one of its corresponding private business process, then the activities that are common to both processes can be associated.
Weaknesses of BPMN
The weaknesses of BPMN could relate to:
ambiguity and confusion in sharing BPMN models support for routine work support for knowledge work, and converting BPMN models to executable environments
EXPRESS (data modeling language)
Fig 1. Requirements of a database for an audio compact disc (CD) collection, presented in EXPRESS-G notation. EXPRESS is a standard data modeling language for product data. EXPRESS is formalized in the ISO Standard for the Exchange of Product model STEP (ISO 10303), and standardized as ISO 10303-11 .
Overview Data models formally define data objects and relationships among data objects for a domain of interest. Some typical applications of data models include supporting the development of databases and enabling the exchange of data for a particular area of interest. Data models are specified in a data modeling language. EXPRESS is a data modeling language defined in ISO 10303-11, the EXPRESS Language Reference Manual.. An EXPRESS data model can be defined in two ways, textually and graphically. For formal verification and as input for tools such as SDAI the textual representation within an ASCII file is the most important one. The graphical representation on the other hand is often more suitable for human use such as explanation and tutorials. The graphical
representation, called EXPRESS-G, is not able to represent all details that can be formulated in the textual form. EXPRESS is similar to programming languages such as PASCAL. Within a SCHEMA various datatypes can be defined together with structural constraints and algorithmic rules. A main feature of EXPRESS is the possibility to formally validate a population of datatypes - this is to check for all the structural and algorithmic rules.
EXPRESS-G EXPRESS-G is a standard graphical notation for information models. It is a useful companion to the EXPRESS language for displaying entity and type definitions, relationships and cardinality. This graphical notation supports a subset of the EXPRESS language. One of the advantages of using EXPRESS-G over EXPRESS is that the structure of a data model can be presented in a more understandable manner. A disadvantage of EXPRESS-G is that complex constraints cannot be formally specified. Figure 1 is an example. The data model presented in figure could be used to specify the requirements of a database for an audio compact disc (CD) collection.
Simple example SCHEMA Family; ENTITY Person ABSTRACT SUPERTYPE OF (ONEOF (Male, Female)); name: STRING; mother: OPTIONAL Female; father: OPTIONAL Male; END_ENTITY; ENTITY Female SUBTYPE OF (Person); END_ENTITY; ENTITY Male SUBTYPE of (Person); END_ENTITY; END_SCHEMA;
The data model is enclosed within the EXPRESS schema Family. It contains a supertype entity Person with the two subtypes Male and Female. Since Person is declared to be ABSTRACT only occurrences of either (ONEOF) the subtype Male or Female can exist. Every occurrence of a person has a mandatory name attribute and optionally attributes mother and father. There is a fixed style of reading for attributes of some entity type:
a Female can play the role of motherfor a Person a Male can play the role of father for a Person
EXPRESS Building blocks Datatypes EXPRESS offers a series of datatypes, with specific data type symbols of the EXPRESSG notation:
Entity data type: This is the most important datatype in EXPRESS. It is covered below in more details. Entity datatypes can be related in two ways, in a subsupertype tree and/or by attributes.
Enumeration data type: Enumeration values are simple strings such as red, green, and blue for an rgb-enumeration. In the case that an enumeration type is declared to be extensible it can be extended in other schemas.
Defined data type. They can be used to specialize other datatypes further on. E.g. it is possible to define the datatype positive which is of type integer with a value > 0.
Select data type: Selects define a choice or an alternative between different options. Most commonly used are selects between different entity_types. More rarely are selects which include defined types. In the case that an enumeration type is declared to be extensible it can be extended in other schemas.
Simple data type o String: This is the most often used simple type. EXPRESS strings can be of any length and can contain any character (ISO 10646/Unicode). However it is common practise. o Binary: This data type is only very rarely used. It covers a number of bits (not bytes). For some implementations the size is limited to 32 bit. o Logical: Similar to the boolean datatype a logical has the possible values TRUE and FALSE and in addition UNKNOWN.
Boolean: With the boolean values TRUE and FALSE. Number: The number data type is a supertype of both, integer and real. Most implementations take uses a double type to represent a real_type, even if the actual value is an integer. o Integer: EXPRESS integers can have in principle any length, but most implementations restricted them to a signed 32 bit value. o Real: Ideally an EXPRESS real value is unlimited in accuracy and size. But in practise a real value is represented by a floating point value of type double. o o
Aggregation data type: The possible kinds of aggregation_types are SET, BAG, LIST and ARRAY. While SET and BAG are unordered, LIST and ARRAY are ordered. A BAG may contain a particular value more than once, this is not allowed for SET. An ARRAY is the only aggregate which may contain unset members. This is not possible for SET, LIST, BAG. The members of an aggregate may be of any other data type
A few general things are to be mentioned for datatypes.
Constructed datatypes can be defined within an EXPRESS schema. They are mainly used to define entities, and to specify the type of entity attributes and aggregate members. Datatypes can be used in a recursive way to build up more and more complex data types. E.g. it is possible to define a LIST of an ARRAY of a SELECT of either some entities or other datatypes. If it makes sense to define such datatypes is a different question. EXPRESS defines a couple of rules how a datatype can be further specialized. This is important for re-declared attributes of entities. GENERIC data types can be used for procedures, functions and abstract entities.
Entity-Attribute Entity attributes allow to add "properties" to entities and to relate one entity with another one in a specific role. The name of the attribute specifies the role. Most datatypes can directly serve as type of an attribute. This includes aggregation as well. There are three different kinds of attributes, explicit, derived and inverse attributes. And all these can be re-declared in a subtype. In addition an explicit attribute can be redeclared as derived in a subtype. No other change of the kind of attributes is possible.
Explicit attributes are those which have direct values visible in a STEP-File. Derived attributes get their values from an expression. In most cases the expression refers to other attributes of THIS instance. The expression may also use EXPRESS functions. Inverse attributes do not add "information" to an entity, but only name and constrain an explicit attribute to an entity from the other end.
Specific attribute symbols of the EXPRESS-G notation:
Supertypes and subtypes An entity can be defined to be a subtype of one or several other entities (multiple inheritance is allowed!). A supertype can have any number of subtypes. It is very common practice in STEP to build very complex sub-supertype graphs. Some graphs relate 100 and more entities with each other. An entity instance can be constructed for either a single entity (if not abstract) or for a complex combination of entities in such a sub-supertype graph. For the big graphs the number of possible combinations is likely to grow in astronomic ranges. To restrict the possible combinations special supertype constraints got introduced such as ONEOF and TOTALOVER. Furthermore an entity can be declared to be abstract to enforce that no instance can be constructed of just this entity but only if it contains a non-abstract subtype.
Algorithmic constraints Entities and defined data types may be further constraint with WHERE rules. WHERE rules are also part of global rules. A WHERE rule is an expression, which must evaluate to TRUE, otherwise a population of an EXPRESS schema, is not valid. Like derived attributes these expression may invoke EXPRESS functions, which may further invoke EXPRESS procedures. The functions and procedures allow formulating complex statements with local variables, parameters and constants - very similar to a programming language. The EXPRESS language can describe local and global rules. For example: ENTITY area_unit SUBTYPE OF (named_unit); WHERE
WR1: (SELF\named_unit.dimensions.length_exponent = 2) AND (SELF\named_unit.dimensions.mass_exponent = 0) AND (SELF\named_unit.dimensions.time_exponent = 0) AND (SELF\named_unit.dimensions.electric_current_exponent = 0) AND (SELF\named_unit.dimensions. thermodynamic_temperature_exponent = 0) AND (SELF\named_unit.dimensions.amount_of_substance_exponent = 0) AND (SELF\named_unit.dimensions.luminous_intensity_exponent = 0); END_ENTITY; -- area_unit
This example describes that area_unit entity must have square value of length. For this the attribute dimensions.length_exponent must be equal to 2 and all other exponents of basic SI units must be 0. Another example: TYPE day_in_week_number = INTEGER; WHERE WR1: (1 <= SELF) AND (SELF <= 7); END_TYPE; -- day_in_week_number
That is, it means that week value cannot exceed 7. And so, you can describe some rules to your entities. More details on the given examples can be found in ISO 10303-41
Extended Enterprise Modeling Language
Example of EEML Goal modeling and process modeling.
Extended Enterprise Modeling Language (EEML) in software engineering is a modelling language used for Enterprise modelling across a number of layers.
Overview Extended Enterprise Modeling Language (EEML) is modelling language, which combines structural modeling, business process modeling, goal modeling with goal hierarchies, and resource modeling. It is used in practice to bridge the type of goal modeling used in common requirements engineering to other modeling approaches. The process logic in EEML is mainly expressed through nested structures of tasks and decision points. The sequencing of tasks is expressed by the flow relation between decision points. Each task has an input port and the output port being decision points for modeling process logic. EEML is intended to be a simple language, which makes it easy to update models. In addition to capturing the various tasks(can consist of several sub-tasks) and their interdependencies, models show which roles perform each task, and the tools, services and information they apply.
History Extended Enterprise Modeling Language (EEML) is end 1990s developed in the EU project EXTERNAL as extension of the Action Port Model (APM) by S. Carlsen (1998). The EXTERNAL project aimed to facilitate inter-organisational cooperation in knowledge intensive industries. It is the hypotheses of the project that interactive process models form a suitable framework for tools and methodologies for dynamically networked organisations. In the project EEML (Extended Enterprise Modelling Language) was first constructed as a common metamodel, designed to enable syntactic and semantic interoperability. It has been further developed in the EU projects Unified Enterprise Modelling Language (EUML) from 2002 to 2003 and the ongoing ATHENA project. The objectives of UEML Working group has been to define, to validate and to disseminate a set of core language constructs to support a Unified Language for Enterprise Modelling, named UEML, to serve as a basis for interoperability within a smart organisation or a network of enterprises.
EEML Topics Modeling domains The EEML-language is divided into 4 sub-languages, with well-defined links across these languages:
Process modeling
Data modeling Resource modeling Goal modeling
Process modeling supports the modeling of process logic which is mainly expressed through nested structures of tasks and decision points. The sequencing of the tasks is expressed by the flow relation between decision points. Each task has minimum an input port and an output port being decision points for modeling process logic, Resource roles are used to connect resources of various kinds (persons, organizations, information, material objects, software tools and manual tools) to the tasks. In addition, data modeling (using UML class diagrams), goal modeling and competency modeling (skill requirements and skills possessed) can be integrated with the process models.
EEML Layers EEML has four layers of interest
Generic Task Type: This layer identifies the constituent tasks of generic, repetitive processes and the logical dependencies between these tasks. Specific Task Type: In this layer process models are expanded, concretised, decomposed and specialised to facilitate business solutions. Manage Task Instances: Here, more detailed decisions are taken regarding work in the actual work environment with its organisational, information, and tool resources. Perform Task Instances: This layer covers the actual execution of tasks.
Goal Modelling Goal Modelling is one of the four EEML modeling domains age. A goal expresses the wanted (or unwanted) state of affairs (either current or future) in a certain context. Example of the goal model is depicted below. It shows goals and relationships between them. It is possible to model advanced goal-relationships in EEML by using goal connectors. A goal connector is used when one need to link several goals.
Goal modeling in EEMLConnecting relationships Goal modeling and process modeling In goal modeling to fulfil Goal1, one must achieve to other goals: both Goal2 and Goal3 (goal-connector with “and” as the logical relation going out). If Goal2 and Goal3 are two different ways of achieving Goal1, then it should be “xor” logical relationship. It can be
an opposite situation when both Goal2 and Goal3 need to be fulfilled and to achieve them one must fulfil Goal1. In this case Goal2 and Goal3 are linked to goal connector and this goal connector has a link to Goal1 with ”and”-logical relationship. The table indicate different types of connecting relationships in EEML goal modeling. Goal model can also be interlinked with a process model.
Goal modelling principles Within requirements engineering (RE), the notion of goal has increasingly been used. Goals generally describe objectives which a system should achieve through cooperation of actors in the intended software and in the environment . Goals are central in some RE frameworks, and can play a supporting role in others. Goal-oriented techniques may particularly be useful in early-phase RE. Early-phase requirements consider e.g. how the intended system meets organizational goals, why the system is needed and how the stakeholders’ interests may be addressed.
Expresses the relationships between systems and their environments : Earlier, requirements engineering focused only on what the system is supposed to do. Over the past years, there has been a more or less mutual understanding, that it is also very important to understand and characterize the interaction between the intended system and its environment. Relationships between systems and their environments are often expressed as goal-based relationships. The motivation for this is “partly today's more dynamic business and organizational environments, where systems are increasingly used to fundamentally change business processes rather than to automate long-established practices”. Goals can also be useful when modelling contexts. Clarifies requirements : Specifying goals leads to asking “why”, “how” and “how else”. Requirements of the stakeholders are often revealed in this process. The stakeholders may seem to be more likely to become aware of potential alternatives for fulfilling their goals, and thereby less likely to over-specify their requirements. Requirements from clients and stakeholders may often be unclear, especially the non-functional ones. A goal-oriented approach allows the requirements to be refined and clarified through an incremental process, by analyzing requirements in terms of goal decomposition. Deals with conflicts : Goals may provide a useful way of dealing with conflicts, such as tradeoffs between costs performance, flexibility, etc, and divergent interests of the stakeholders. Goals can deal with conflicts because meeting of one goal can interfere with the meeting of others. Different opinions on how to meet a goal has led to different ways of handling conflicts. Decides requirements completeness : Requirements can be considered complete if they fulfil explicit goals in the requirement model. Connects requirements to design : Goals can be used in order to connect the requirements to the design. For some, goals are an important mechanism in this matter. (The Non-Functional Requirements (NFR) framework uses goals to guide the design process.)
Goal-oriented Requirements Language
GRL Notation Goal-oriented Requirements Language (GRL) is a language that is designed to support goal-oriented modeling and reasoning about requirements, especially the non-functional requirements It allows to express conflict between goals and helps to make decisions that resolve conflicts. There are three main categories of concepts in GRL: intentional elements, intentional relationships and actors . They are called for intentional because they are used in models that primarily concerned with answering "why" question of requirements (for ex. why certain choices for behavior or structure were made, what alternatives exist and what is the reason for choosing of certain alternative.)
Flowchart A flowchart is a common type of chart, that represents an algorithm or process, showing the steps as boxes of various kinds, and their order by connecting these with arrows. Flowcharts are used in analyzing, designing, documenting or managing a process or program in various fields.
History The first structured method for documenting process flow, the "flow process chart", was introduced by Frank Gilbreth to members of ASME in 1921 as the presentation “Process Charts—First Steps in Finding the One Best Way”. Gilbreth's tools quickly found their way into industrial engineering curricula. In the early 1930s, an industrial engineer, Allan H. Mogensen began training business people in the use of some of the tools of industrial engineering at his Work Simplification Conferences in Lake Placid, New York. A 1944 graduate of Mogensen's class, Art Spinanger, took the tools back to Procter and Gamble where he developed their Deliberate Methods Change Program. Another 1944 graduate, Ben S. Graham, Director of Formcraft Engineering at Standard Register Corporation, adapted the flow process chart to information processing with his development of the multi-flow process chart to displays multiple documents and their relationships. In 1947, ASME adopted a symbol set derived from Gilbreth's original work as the ASME Standard for Process Charts by Mishad,Ramsan,Raiaan.
Douglas Hartree explains that Herman Goldstine and John von Neumann developed the flow chart (originally, diagram) to plan computer programs. His contemporary account is endorsed by IBM engineers and by Goldstine's personal recollections. The original programming flow charts of Goldstine and von Neumann can be seen in their unpublished report, "Planning and coding of problems for an electronic computing instrument, Part II, Volume 1," 1947, which is reproduced in von Neumann's collected works. Flowcharts used to be a popular means for describing computer algorithms and are still used for this purpose. Modern techniques such as UML activity diagrams can be considered to be extensions of the flowchart. However, their popularity decreased when, in the 1970s, interactive computer terminals and third-generation programming languages became the common tools of the trade, since algorithms can be expressed much more concisely and readably as source code in such a language. Often, pseudo-code is used, which uses the common idioms of such languages without strictly adhering to the details of a particular one.
Flowchart building blocks Symbols A typical flowchart from older Computer Science textbooks may have the following kinds of symbols: Start and end symbols Represented as circles, ovals or rounded rectangles, usually containing the word "Start" or "End", or another phrase signaling the start or end of a process, such as "submit enquiry" or "receive product". Arrows Showing what's called "flow of control" in computer science. An arrow coming from one symbol and ending at another symbol represents that control passes to the symbol the arrow points to. Processing steps Represented as rectangles. Examples: "Add 1 to X"; "replace identified part"; "save changes" or similar. Input/Output Represented as a parallelogram. Examples: Get X from the user; display X. Conditional or decision Represented as a diamond (rhombus). These typically contain a Yes/No question or True/False test. This symbol is unique in that it has two arrows coming out of it, usually from the bottom point and right point, one corresponding to Yes or True, and one corresponding to No or False. The arrows should always be labeled. More than two arrows can be used, but this is normally a clear indicator that a complex decision is being taken, in which case it may need to be broken-down further, or replaced with the "pre-defined process" symbol.
A number of other symbols that have less universal currency, such as:
A Document represented as a rectangle with a wavy base; A Manual input represented by parallelogram, with the top irregularly sloping up from left to right. An example would be to signify data-entry from a form; A Manual operation represented by a trapezoid with the longest parallel side at the top, to represent an operation or adjustment to process that can only be made manually. A Data File represented by a cylinder.
Flowcharts may contain other symbols, such as connectors, usually represented as circles, to represent converging paths in the flowchart. Circles will have more than one arrow coming into them but only one going out. Some flowcharts may just have an arrow point to another arrow instead. These are useful to represent an iterative process (what in Computer Science is called a loop). A loop may, for example, consist of a connector where control first enters, processing steps, a conditional with one arrow exiting the loop, and one going back to the connector. Off-page connectors are often used to signify a connection to a (part of another) process held on another sheet or screen. It is important to remember to keep these connections logical in order. All processes should flow from top to bottom and left to right.
Examples A flowchart for computing factorial N (N!) where N! = (1 * 2 * 3 * ... * N). This flowchart represents a "loop and a half" — a situation discussed in introductory programming textbooks that requires either a duplication of a component (to be both inside and outside the loop) or the component to be put inside a branch in the loop.
Types of flowcharts There are many different types of flowcharts. On the one hand there are different types for different users, such as analysts, designers, engineers, managers, or programmers. On the other hand those flowcharts can represent different types of objects. Sterneckert (2003) divides four more general types of flowcharts:
Document flowcharts, showing a document flow through system Data flowcharts, showing data flows in a system System flowcharts showing controls at a physical or resource level Program flowchart, showing the controls in a program within a system
However there are several of these classifications. For example Andrew Veronis (1978) named three basic types of flowcharts: the system flowchart, the general flowchart, and the detailed flowchart. That same year Marilyn Bohl (1978) stated "in practice, two kinds of flowcharts are used in solution planning: system flowcharts and program flowcharts...". More recently Mark A. Fryman (2001) stated that there are more differences. Decision flowcharts, logic flowcharts, systems flowcharts, product
flowcharts, and process flowcharts are "just a few of the different types of flowcharts that are used in business and government.
Software Manual Any vector-based drawing program can be used to create flowchart diagrams, but these will have no underlying data model to share data with databases or other programs such as project management systems or spreadsheets. Some tools offer special support for flowchart drawing, e.g., ConceptDraw, SmartDraw, Visio, and OmniGraffle.
Automatic Many software packages exist that can create flowcharts automatically, either directly from source code, or from a flowchart description language. For example, Graph::Easy, a Perl package, takes a textual description of the graph, and uses the description to generate various output formats including HTML, ASCII or SVG.
Web-based Recently, online flowchart solutions have become available, e.g., DrawAnywhere. It is easy to use and flexible but does not meet the power of off-line software like Visio or SmartDraw.
Extended Enterprise Modeling Language
Example of EEML Goal modeling and process modeling. Extended Enterprise Modeling Language (EEML) in software engineering is a
Overview Extended Enterprise Modeling Language (EEML) is modelling language, which combines structural modeling, business process modeling, goal modeling with goal hierarchies, and resource modeling. It is used in practice to bridge the type of goal modeling used in common requirements engineering to other modeling approaches. The process logic in EEML is mainly expressed through nested structures of tasks and decision points. The sequencing of tasks is expressed by the flow relation between decision points. Each task has an input port and the output port being decision points for modeling process logic. EEML is intended to be a simple language, which makes it easy to update models. In addition to capturing the various tasks(can consist of several sub-tasks) and their interdependencies, models show which roles perform each task, and the tools, services and information they apply.
History Extended Enterprise Modeling Language (EEML) is end 1990s developed in the EU project EXTERNAL as extension of the Action Port Model (APM) by S. Carlsen (1998). The EXTERNAL project aimed to facilitate inter-organisational cooperation in knowledge intensive industries. It is the hypotheses of the project that interactive process models form a suitable framework for tools and methodologies for dynamically networked organisations. In the project EEML (Extended Enterprise Modelling Language) was first constructed as a common metamodel, designed to enable syntactic and semantic interoperability. It has been further developed in the EU projects Unified Enterprise Modelling Language (EUML) from 2002 to 2003 and the ongoing ATHENA project. The objectives of UEML Working group has been to define, to validate and to disseminate a set of core language constructs to support a Unified Language for Enterprise Modelling, named UEML, to serve as a basis for interoperability within a smart organisation or a network of enterprises.
EEML Topics Modeling domains The EEML-language is divided into 4 sub-languages, with well-defined links across these languages:
Process modeling Data modeling Resource modeling Goal modeling
Process modeling supports the modeling of process logic which is mainly expressed through nested structures of tasks and decision points. The sequencing of the tasks is expressed by the flow relation between decision points. Each task has minimum an input port and an output port being decision points for modeling process logic, Resource roles are used to connect resources of various kinds (persons, organizations, information, material objects, software tools and manual tools) to the tasks. In addition, data modeling (using UML class diagrams), goal modeling and competency modeling (skill requirements and skills possessed) can be integrated with the process models.
EEML Layers EEML has four layers of interest
Generic Task Type: This layer identifies the constituent tasks of generic, repetitive processes and the logical dependencies between these tasks. Specific Task Type: In this layer process models are expanded, concretised, decomposed and specialised to facilitate business solutions. Manage Task Instances: Here, more detailed decisions are taken regarding work in the actual work environment with its organisational, information, and tool resources. Perform Task Instances: This layer covers the actual execution of tasks.
Goal Modelling Goal Modelling is one of the four EEML modeling domains age. A goal expresses the wanted (or unwanted) state of affairs (either current or future) in a certain context. Example of the goal model is depicted below. It shows goals and relationships between them. It is possible to model advanced goal-relationships in EEML by using goal connectors. A goal connector is used when one need to link several goals.
Goal modeling in EEMLConnecting relationships Goal modeling and process modeling In goal modeling to fulfil Goal1, one must achieve to other goals: both Goal2 and Goal3 (goal-connector with “and” as the logical relation going out). If Goal2 and Goal3 are two
different ways of achieving Goal1, then it should be “xor” logical relationship. It can be an opposite situation when both Goal2 and Goal3 need to be fulfilled and to achieve them one must fulfil Goal1. In this case Goal2 and Goal3 are linked to goal connector and this goal connector has a link to Goal1 with ”and”-logical relationship. The table indicate different types of connecting relationships in EEML goal modeling. Goal model can also be interlinked with a process model.
Goal modelling principles Within requirements engineering (RE), the notion of goal has increasingly been used. Goals generally describe objectives which a system should achieve through cooperation of actors in the intended software and in the environment . Goals are central in some RE frameworks, and can play a supporting role in others. Goal-oriented techniques may particularly be useful in early-phase RE. Early-phase requirements consider e.g. how the intended system meets organizational goals, why the system is needed and how the stakeholders’ interests may be addressed.
Expresses the relationships between systems and their environments : Earlier, requirements engineering focused only on what the system is supposed to do. Over the past years, there has been a more or less mutual understanding, that it is also very important to understand and characterize the interaction between the intended system and its environment. Relationships between systems and their environments are often expressed as goal-based relationships. The motivation for this is “partly today's more dynamic business and organizational environments, where systems are increasingly used to fundamentally change business processes rather than to automate long-established practices”. Goals can also be useful when modelling contexts. Clarifies requirements : Specifying goals leads to asking “why”, “how” and “how else”. Requirements of the stakeholders are often revealed in this process. The stakeholders may seem to be more likely to become aware of potential alternatives for fulfilling their goals, and thereby less likely to over-specify their requirements. Requirements from clients and stakeholders may often be unclear, especially the non-functional ones. A goal-oriented approach allows the requirements to be refined and clarified through an incremental process, by analyzing requirements in terms of goal decomposition. Deals with conflicts : Goals may provide a useful way of dealing with conflicts, such as tradeoffs between costs performance, flexibility, etc, and divergent interests of the stakeholders. Goals can deal with conflicts because meeting of one goal can interfere with the meeting of others. Different opinions on how to meet a goal has led to different ways of handling conflicts. Decides requirements completeness : Requirements can be considered complete if they fulfil explicit goals in the requirement model. Connects requirements to design : Goals can be used in order to connect the requirements to the design. For some, goals are an important mechanism in this
matter. (The Non-Functional Requirements (NFR) framework uses goals to guide the design process.)
Goal-oriented Requirements Language
GRL Notation Goal-oriented Requirements Language (GRL) is a language that is designed to support goal-oriented modeling and reasoning about requirements, especially the non-functional requirements It allows to express conflict between goals and helps to make decisions that resolve conflicts. There are three main categories of concepts in GRL: intentional elements, intentional relationships and actors . They are called for intentional because they are used in models that primarily concerned with answering "why" question of requirements (for ex. why certain choices for behavior or structure were made, what alternatives exist and what is the reason for choosing of certain alternative.)
Fundamental modeling concepts Fundamental Modeling Concepts (FMC) provide a framework to describe softwareintensive systems. It strongly emphasizes the communication about software-intensive systems by using a semi-formal graphical notation that can easily be understood.
Introduction FMC distinguishes three perspectives to look at a software system:
Structure of the system Processes in the system Value domains of the system
FMC defines a dedicated diagram type for each perspective. FMC diagrams use a simple and lean notation. The purpose of FMC diagrams is to facilitate the communication about a software system, not only between technical experts but also between technical experts and business or domain experts. The comprehensibility of FMC diagrams has made them famous among its supporters. The common approach when working with FMC is to start with a high-level diagram of the compositional structure of a system. This “big picture” diagram serves as a reference
in the communication with all involved stakeholders of the project. Later on, the highlevel diagram is iteratively refined to model technical details of the system. Complementary diagrams for processes observed in the system or value domains found in the system are introduced as needed.
Diagram Types FMC uses three diagram types to model different aspects of a system:
Compositional Structure Diagram depicts the static structure of a system. This diagram type is also known as FMC Block Diagram Dynamic Structure Diagram depicts processes that can be observed in a system. This diagram type is also known as FMC Petri-net Value Range Structure Diagram depicts structures of values found in the system. This diagram type is also known as FMC E/R Diagram
All FMC diagrams are bipartite graphs. Each Bipartite graph consists of two disjoint sets of vertices with the condition that no vertex is connected to another vertex of the same set. In FMC diagrams, members of one set are represented by angular shapes, and members of the other set are represented by curved shapes. Each element in an FMC diagram can be refined by another diagram of the same type, provided that the combined graph is also bipartite. This mechanism allows modeling all relevant layers of abstraction with the same notation.
Compositional Structure Diagram Compositional structure diagrams depict the static structure of a system, and the relationships between system components. System components can be active or passive. Agents are active system components. They perform activities in the system. Storages and channels are passive components which store or transmit information. The image to the right is an example of a compositional structure diagram. It contains the agents Order Processor, Supplier Manager, Supplier, Online Shop and an unnamed human agent. Agents are represented by rectangles. The dots and the shadow of the agent Supplier indicate that this agent has multiple instances, i.e. the Supplier Manager communicates with one or many suppliers. The so called human agent represents a user interacting with the system. The diagram contains the storages Orders, Purchase Order and Product Catalog. Storages are represented by curved shapes. Agents can read from storages, write to storages or modify the content of storages. The directions of the arrows indicate which operation is performed by an agent. In the diagram, the Supplier Manager can modify the content of the Product Catalog, whereas the Order Processor can only read the content of the Product Catalog.
Agents communicate via channels. The direction of information flow is either indicated by arrows (not shown in the picture), by a request-response-symbol (e.g. between Supplier Manager and Supplier) or omitted (e.g. between Order Processor and Supplier Manager).
Dynamic Structure Diagram Dynamic structures are derived from petri nets. "They are used to express system behavior over time, depicting the actions performed by the agents. So they clarify how a system is working and how communication takes place between different agents."
Value Range Structure Diagram Value range structure diagrams (also known as FMC Entity Relationship Diagrams) can be compared with the Entity-relationship model. "[They] are used to depict value range structures or topics as mathematical structures. Value range structures describe observable values at locations within the system whereas topic diagrams allow a much wider usage in order to cover all correlations between interesting points."
IDEF
IDEF Methods: Part of the Systems Engineer’s Toolbox
IDEF (Integration DEFinition) is a family of modeling languages in the field of systems and software engineering. They cover a wide range of uses, from functional modeling to data, simulation, object-oriented analysis/design and knowledge acquisition. These "definition languages" were developed under funding from U.S. Air Force and although still most commonly used by them, as well as other military and Department of Defense (DoD) agencies, are in the public domain. The most-widely recognized and used of the IDEF family are IDEF0, a functional modeling language building on SADT, and IDEF1X, which addresses information models and database design issues.
History IDEF originally stands for ICAM Definition, that were initiated in the 1970s at the US Air Force Materials Laboratory, Wright-Patterson Air Force Base in Ohio by Dennis E. Wisnosky and Dan L. Shunk and others. and finished being developed in the 1980s. IDEF was a product of the Integrated Computer-Aided Manufacturing (ICAM) initiative of the United States Air Force. "IDEF" initially stood for "ICAM DEFinition" language; the IEEE standards recast IDEF as "Integration DEFinition." The specific projects that produced IDEF were ICAM project priorities 111 and 112 (later renumber 1102). The subsequent Integrated Information Support System (IISS) project priorities 6201, 6202, and 6203 were an effort to create an information processing environment that could be run in heterogeneous physical computing environments. Further development of IDEF occurred under those projects as a result of experience gained applying the new modeling techniques. The intent of the IISS efforts was to create 'generic subsystems' which could be used by a large number of collaborating enterprises, such as U.S. Defense contractors and the armed forces of friendly nations.
Functional modeling
Example of an IDEF0 diagram: A function model of the process of "Maintain Reparable Spares".
The IDEF0 Functional Modeling method is designed to model the decisions, actions, and activities of an organization or system. It was derived from the established graphic modeling language Structured Analysis and Design Technique (SADT) developed by Douglas T. Ross and SofTech, Inc.. In its original form, IDEF0 includes both a definition of a graphical modeling language (syntax and semantics) and a description of a comprehensive methodology for developing models. The US Air Force commissioned the SADT developers to develop a function model method for analyzing and communicating the functional perspective of a system. IDEF0 should assist in organizing system analysis and promote effective communication between the analyst and the customer through simplified graphical devices.
Information modeling At the time of the ICAM 1102 effort there were numerous, mostly incompatible, data model methods for storing computer data — Sequential (VSAM), Hierarchical (IMS), Network (Cincom's TOTAL and CODASYL, and Cullinet's IDMS). The relational data model was just emerging as a promising way of thinking about structuring data for easy, efficient, and accurate access. Relational Database Management Systems had not yet emerged as a general standard for data management. The ICAM program office deemed it valuable to create a "neutral" way of describing the data content of large-scale systems. The emerging academic literature suggested that methods were needed to process data independently of the way it was physically stored. Thus the IDEF1 language was created to allow a neutral description of data structures, that could be equally applied regardless of the storage method or file access method. IDEF1 was developed under ICAM program priority 1102 by Dr. Robert R. Brown of the Hughes Aircraft Company, under contract to SofTech, Inc. Dr. Brown had previously been responsible for the development of IMS while working at Rockwell International (Rockwell chose not to pursue IMS as a marketable product; International Business Machines (IBM), which had served as a support contractor during development, subsequently took over the product and was successful in further developing it for market.) Dr. Brown credits his Hughes colleague Mr. Timothy Ramey as the inventor of IDEF1 as a viable formalism for modeling information structures. The two Hughes researchers built on ideas from and interactions with many luminaries in the field at the time. In particular, IDEF1 draws on the following techniques:
the Evolving Natural Language Information Model (ENALIM) technique of Dr. G. M. Nijssen (Control Data Corporation) — this technique is now more widely known as NIAM or the Object-Role Model ORM; the network data structures technique, popularly called the CODASYL approach, of Dr. Charles Bachman (Honeywell Information Systems); the hierarchical data management technique, implemented in IBM's IMS data management system, developed by Dr. R. R. Brown (Rockwell International); the relational approach to data of Dr. E. F. Codd (IBM); The Entity-Relationship Approach (E-R) of Dr. Peter Chen (UCLA).
The effort to develop IDEF1 resulted in both a new method for information modeling and an example of its use in the form of a "reference information model of manufacturing." This latter artifact was developed by D. S. Coleman of the D. Appleton & Company (DACOM) acting as a sub-contractor to Hughes and under the direction of Mr. Ramey. Personnel at DACOM became quite expert at IDEF1 modeling and subsequently produced a training course and accompanying materials for the IDEF1 modeling technique. Experience with IDEF1 revealed that the translation of information requirements into database designs was more difficult than had originally be anticipated. The most beneficial value of the IDEF1 information modeling technique was its ability to represent data independent of how those data were to be stored and used. It provided data modelers and data analysts with a way to represent data requirements during the requirementsgathering process. This allowed designers to face the decision of which DBMS to use under various circumstances after the nature of the data requirements was understood. The result was reduction of the "misfit" of data requirements to the capabilities, and limitations, of the DBMS. The translation from IDEF1 models to database designs proved to be difficult, however.
IDEF1X
Example of an IDEF1X Diagram. To satisfy the data modeling enhancement requirements that were identified in the IISS6202 project, a sub-contractor, DACOM, obtained a license to the Logical Database Design Technique (LDDT) and its supporting software (ADAM). LDDT had been developed in 1982 by Robert G. Brown of The Database Design Group entirely outside the IDEF program and with no knowledge of IDEF1. LDDT combined elements of the relational data model, the E-R model, and generalization in a way specifically intended to support data modeling and the transformation of the data models into database designs. The graphic syntax of LDDT differed from that of IDEF1 and, more importantly, LDDT contained interrelated modeling concepts not present in IDEF1. Mary E. Loomis wrote a
concise summary of the syntax and semantics of a substantial subset of LDDT, using terminology compatible with IDEF1 wherever possible. DACOM labeled the result IDEF1X and supplied it to the ICAM program. Because the IDEF program was funded by the government, the techniques are in the public domain. In addition to the ADAM software, sold by DACOM under the name Leverage, a number of CASE tools, such as ERwin, use IDEF1X as their representation technique for data modeling. The IISS projects actually produced working prototypes of an information processing environment that would run in heterogeneous computing environments. Current advancements in such techniques as Java and JDBC are now achieving the goals of ubiquity and versatility across computing environments which was first demonstrated by IISS.
IDEF2 and IDEF3
Example of an Enhanced Transition Schematic, modelled with IDEF3. The third IDEF (IDEF2) was originally intended as a user interface modeling method. However, since the Integrated Computer-Aided Manufacturing (ICAM) Program needed a simulation modeling tool, the resulting IDEF2 was a method for representing the time varying behavior of resources in a manufacturing system, providing a framework for specification of math model based simulations. It was the intent of the methodology program within ICAM to rectify this situation but limitation of funding did not allow this to happen. As a result, the lack of a method which would support the structuring of descriptions of the user view of a system has been a major shortcoming of the IDEF system. The basic problem from a methodology point of view is the need to distinguish between a description of what a system (existing or proposed) is supposed to do and a representative simulation model that will predict what a system will do. The latter was the focus of IDEF2, the former is the focus of IDEF3.
IDEF 4
Example of the IDEF4: An Behavior Diagram for methods Implementing Louder. The development of IDEF4 came from the recognition that the modularity, maintainability and code reusability that results from the object oriented programming paradigm can be realized in traditional data processing applications. The proven ability of the object oriented programming paradigm to support data level integration in large complex distributed systems is also a major factor in the widespread interest in this technology from the traditional data processing community. IDEF4 was developed as a design tool for software designers who use object-oriented languages such as the Common LISP Object System, Flavors, C++, SmallTalk, Objective C and others. Since effective usage of the object-oriented paradigm requires a different thought process than used with conventional procedural or database languages, standard methodologies such as structure charts, data flow diagrams, and traditional data design models (hierarchical, relational, and network) are not sufficient. IDEF4 seeks to provide the necessary facilities to support the object-oriented design decision making process.
IDEF5
Example of an IDEF5 Composition Schematic for a Ballpoint Pen. IDEF5 or Integrated Definition for Ontology Description Capture Method is a software engineering method to develop and maintain usable, accurate, domain ontologies. In the field of computer science ontologies are used to capture the concept and objects in a specific domain, along with associated relationships and meanings. In addition, ontology
capture helps coordinate projects by standardizing terminology and creates opportunities for information reuse. The lDEF5 Ontology Capture Method has been developed to reliably construct ontologies in a way that closely reflects human understanding of the specific domain. In the IDEF5 method, an ontology is constructed by capturing the content of certain assertions about real-world objects, their properties, and their interrelationships and representing that content in an intuitive and natural form. The IDEF5 method has three main components: A graphical language to support conceptual ontology analysis, a structured text language for detailed ontology characterization, and a systematic procedure that provides guidelines for effective ontology capture.
IDEF6
IDEF6 model of IDEF4 Design Activities IDEF6 or Integrated Definition for Design Rationale Capture is a method to facilitate the acquisition, representation, and manipulation of the design rationale used in the development of enterprise systems. Rationale is the reason, justification, underlying motivation, or excuse that moved the designer to select a particular strategy or design feature. More simply, rationale is interpreted as the answer to the question, “Why is this design being done in this manner?” Most design methods focus on the what the design is (i.e., on the final product, rather than why the design is the way it is). IDEF6 will be a method that possesses the conceptual resources and linguistic capabilities needed (i) to represent the nature and structure of the information that constitutes design rationale within a given system, and (ii) to associate that rationale with design specifications, models, and documentation for the system. The scope of IDEF6 applicability covers all phases of the information system development process, from initial conceptualization through both preliminary and detailed design activities. To the extent that detailed design decisions for software systems are relegated to the coding phase, the IDEF6 technique should be usable during the software construction process as well.
IDEF8
IDEF8 or Integrated Definition for Human-System Interaction Design is a method for producing high-quality designs of the interactions that occur between users and the systems they operate. Systems are characterized as a collection of objects which perform functions to accomplish a particular goal. The system with which the user interacts can be any system, not necessarily a computer program. Human-system interactions are designed at three levels of specification within the IDEF8 method. The first level defines the philosophy of system operation and produces a set of models and textual descriptions of overall system processes. The second level of design specifies role-centered scenarios of system use. The third level of IDEF8 design is for human-system design detailing. At this level of design, IDEF8 provides a library of metaphors to help users and designers specify the desired behavior in terms of other objects whose behavior is more familiar. Metaphors provide a model of abstract concepts in terms of familiar, concrete objects and experiences.
IDEF9
Typical business systems. IDEF9 or Integrated Definition for Business Constraint Discovery is designed to assist in the discovery and analysis of constraints in a business system. A primary motivation driving the development of IDEF9 was an acknowledgment that the collection of constraints that forge an enterprise system is generally poorly defined. The knowledge of what constraints exist and how those constraints interact is incomplete, disjoint, distributed, and often completely unknown. This situation is not necessarily alarming. Just as living organisms do not need to be aware of the genetic or autonomous constraints that govern certain behaviors, organizations can (and most do) perform well without explicit knowledge of the glue that structures the system. However, if the desire exists to modify the business in a predictable manner, the knowledge of these constraints is as critical as knowledge of genetics is to the genetic engineer.
IDEF14
IDEF14 or Integrated Definition for Network Design Method is a method that targets at modeling and designing computer and communication networks. It can be used to model existing ("as is") computer networks or envisioned ("to be") computer networks. It helps the network designer work with "what if" potential network designs and document design rationale. The fundamental goals of the IDEF14 method research project have developed from a perceived need for good network designs that can be implemented quickly and accurately.
IDEF Methods Eventually the IDEF methods have been defined up to IDEF14:
IDEF0 : Function modeling IDEF1 : Information Modeling IDEF1X : Data Modeling IDEF2 : Simulation Model Design IDEF3 : Process Description Capture IDEF4 : Object-Oriented Design IDEF5 : Ontology Description Capture IDEF6 : Design Rationale Capture IDEF7 : Information System Auditing IDEF8 : User Interface Modeling IDEF9 : Business Constraint Discovery IDEF10 : Implementation Architecture Modeling IDEF11 : Information Artifact Modeling IDEF12 : Organization Modeling IDEF13 : Three Schema Mapping Design IDEF14 : Network Design
In 1995 only the IDEF0, IDEF1X, IDEF2, IDEF3 and IDEF4 had been developed in full. Some of the other IDEF concepts had some prelimary design. Some of the last efforts were new IDEF developments in 1995 toward establishing reliable methods for business constraint discovery IDEF9, design rationale capture IDEF6, humansystem interaction design IDEF8, and network design IDEF14. In 2009 the methods IDEF7, IDEF10, IDEF11, IDEF 12 and IDEF13 haven't been developed any further then their initial definition.
Jackson Structured Programming Jackson Structured Programming or JSP is a method for structured programming based on correspondences between data stream structure and program structure. JSP structures programs and data in terms of sequences, iterations and selections, and as a consequence it is applied when designing a program's detailed control structure, below the level where object-oriented methods become important.
Introduction JSP was originally developed in the 1970s by Michael A. Jackson and documented in his 1975 book Principles of Program Design. Jackson's aim was to make COBOL batch file processing programs easier to modify and maintain, but the method can be used to design programs for any programming language that has structured control constructs, languages such as C, Java and Perl. Despite its age, JSP is still in use and is supported by diagramming tools such as Microsoft's Visio and CASE tools such as Jackson Workbench . Jackson Structured Programming was seen by many as related to Warnier Structured Programming, but the latter method focused almost exclusively on the structure of the output stream. JSP and Warnier's method both structure programs and data using only sequences, iterations and selections, so they essentially create programs that are parsers for regular expressions which simultaneously match the program's input and output data streams. Because JSP focusses on the existing input and output data streams, designing a program using JSP is claimed to be more straightforward than with other structured programming methods, avoiding the leaps of intuition needed to successfully program using methods such as top-down decomposition. Another consequence of JSP's focus on data streams is that it creates program designs with a very different structure to the kind created by the stepwise refinement methods of Wirth and Dijkstra. One typical feature of the structure of JSP programs is that they have several input operations distributed throughout the code in contrast to programs designed using stepwise refinement, which tend to have only one input operation. Jackson illustrates this difference in Chapter 3 of Principles of Program Design. He presents two versions of a program, one designed using JSP, the other using 'traditional' methods.
Structural equivalent The JSP version of the program is structurally equivalent to String line; line = in.readLine(); while (line != null) { int count = 0; String firstLineOfGroup = line; while (line != null && line.equals(firstLineOfGroup)) { count++; line = in.readLine(); } System.out.println(firstLineOfGroup + " " + count); }
and the traditional version of the program is equivalent to String line; int count = 0; String firstLineOfGroup = null; while ((line = in.readLine()) != null) { if (firstLineOfGroup == null || !line.equals(firstLineOfGroup)) { if (firstLineOfGroup != null) { System.out.println(firstLineOfGroup + " " + count); } count = 0; firstLineOfGroup = line; } count++; } if (firstLineOfGroup != null) { System.out.println(firstLineOfGroup + " " + count); }
Jackson criticises the traditional version, claiming that it hides the relationships which exist between the input lines, compromising the programs understandability and maintainability by, for example, forcing the use of a special case for the first line and forcing another special case for a final output operation.
The method JSP uses semi-formal steps to capture the existing structure of a program's inputs and outputs in the structure of the program itself. The intent is to create programs which are easy to modify over their lifetime. Jackson's major insight was that requirement changes are usually minor tweaks to the existing structures. For a program constructed using JSP, the inputs, the outputs, and the internal structures of the program all match, so small changes to the inputs and outputs should translate into small changes to the program. JSP structures programs in terms of four component types:
fundamental operations sequences iterations selections
The method begins by describing a program's inputs in terms of the four fundamental component types. It then goes on to describe the program's outputs in the same way. Each input and output is modelled as a separate Data Structure Diagram (DSD). To make JSP work for compute-intensive applications, such as digital signal processing (DSP) it is also
necessary to draw algorithm structure diagrams, which focus on internal data structures rather than input and output ones. The input and output structures are then unified or merged into a final program structure, known as a Program Structure Diagram (PSD). This step may involve the addition of a small amount of high level control structure to marry up the inputs and outputs. Some programs process all the input before doing any output, whilst others read in one record, write one record and iterate. Such approaches have to be captured in the PSD. The PSD, which is language neutral, is then implemented in a programming language. JSP is geared towards programming at the level of control structures, so the implemented designs use just primitive operations, sequences, iterations and selections. JSP is not used to structure programs at the level of classes and objects, although it can helpfully structure control flow within a class's methods. JSP uses a diagramming notation to describe the structure of inputs, outputs and programs, with diagram elements for each of the fundamental component types. A simple operation is drawn as a box.
An operation A sequence of operations is represented by boxes connected with lines. In the example below, operation A consists of the sequence of operations B, C and D.
A sequence An iteration is again represented with joined boxes. In addition the iterated operation has a star in the top right corner of its box. In the example below, operation A consists of an iteration of zero or more invocations of operation B.
An iteration Selection is similar to a sequence, but with a circle drawn in the top right hand corner of each optional operation. In the example, operation A consists of one and only one of operations B, C or D.
A selection
A worked example
As an example, here is how a programmer would design and code a run length encoder using JSP. A run length encoder is a program which takes as its input a stream of bytes. It outputs a stream of pairs consisting of a byte along with a count of the byte's consecutive occurrences. Run length encoders are often used for crudely compressing bitmaps. With JSP, the first step is to describe the structure of a program's inputs. A run length encoder has only one input, a stream of bytes which can be viewed as zero or more runs. Each run consists of one or more bytes of the same value. This is represented by the following JSP diagram.
The run length encoder input The second step is to describe the structure of the output. The run length encoder output can be described as zero or more pairs, each pair consisting of a byte and its count. In this example, the count will also be a byte.
The run length encoder output The next step is to describe the correspondences between the operations in the input and output structures.
The correspondences between the run length encoders inputs and its outputs It is at this stage that the astute programmer may encounter a structure clash, in which there is no obvious correspondence between the input and output structures. If a structure clash is found, it is usually resolved by splitting the program into two parts, using an intermediate data structure to provide a common structural framework with which the two program parts can communicate. The two programs parts are often implemented as processes or coroutines. In this example, there is no structure clash, so the two structures can be merged to give the final program structure.
The run length encoder program structure At this stage the program can be fleshed out by hanging various primitive operations off the elements of the structure. Primitives which suggest themselves are 1. read a byte 2. remember byte
3. 4. 5. 6.
set counter to zero increment counter output remembered byte output counter
The iterations also have to be fleshed out. They need conditions added. Suitable conditions would be 1. while there are more bytes 2. while there are more bytes and this byte is the same as the run's first byte and the count will still fit in a byte If we put all this together, we can convert the diagram and the primitive operations into C, maintaining a one-to-one correspondence between the code and the operations and structure of the program design diagram. #include <stdio.h> #include <stdlib.h> int main(int argc, char *argv[]) { int c; c = getchar(); while (c != EOF) { int count = 1; int first_byte = c; c = getchar(); while (c != EOF && c == first_byte && count < 255) { count++; c = getchar(); } putchar(first_byte); putchar(count); } return EXIT_SUCCESS; }
Criticism This method will work only when translation from input to output is equivalent to a context-free grammar.
Lepus3
LePUS3 is an object-oriented, visual Design Description Language, namely a software modelling language and a formal specification language that is suitable primarily for modelling large object-oriented (Java, C++, C#) programs and design motifs such as design patterns . It is defined as an axiomatized subset of First-order predicate logic. LePUS is an abbreviation for Language for Pattern Uniform Specification.
Purpose LePUS3 is tailored for the following purposes:
Scalability: To model industrial-scale programs using small charts with only few symbols Automated verifiability: To allow programmers to continuously keep the design in synch with the implementation Program visualization: To allow tools to reverse-engineer legible charts from plain source code modelling their design Pattern implementation: To allow tools to determine automatically whether your program implements a design pattern Design abstraction: To specify unimplemented programs without committing prematurely to implementation minutiae Genericity: To model a design pattern not as a specific implementation but as a design motif Rigour: To allow software designers to be sure exactly what design charts mean and reason rigorously about them
Context LePUS3 belongs to the following families of languages:
Object oriented software modelling languages (e.g., UML): LePUS3 is a visual notation that is used to represent the building-blocks in the design of programs object-oriented programming languages Formal specification Languages: Like other Logic Visual Languages, LePUS3 charts articulate sentences in mathematical logic. LePUS3 is axiomatized in and defined as a recursive (turing-decidable) subset of first-order predicate calculus. Its semantics are defined using finite structure (mathematical logic). Architecture Description Languages: LePUS3 is a non-functional specification language used to represent design decisions about programs in class-based objectoriented programming languages (such as Java and C++). Tool supported specification languages: Verification of LePUS3 charts (checking their consistency with a Java 1.4 program) can be established (‘verified’) by a click of a button, as demonstrated by the Two-Tier Programming Toolkit.
Program Visualization Notations are notations which offer a graphical representation of the program, normally generated by reverse-engineering the source code of the program.
Vocabulary LePUS3 was designed to accommodate for parsimony and for economy of expression. Its vocabulary consists of only 15 visual tokens.
Tool support Version 0.5.1 of the Two-Tier Programming Toolkit can be used to create LePUS3 specifications (charts), automatically verifying their consistency with Java 1.4 programs, and for reverse-engineering these charts from Java source code.
Design Patterns LePUS3 was specifically designed to model, among others, the 'Gang of Four' design patterns, including Abstract Factory, Factory Method, Adapter, Decorator, Composite, Proxy, Iterator, State, Strategy, Template Method, and Visitor. (See "The 'Gang of Four' Companion") The abbreviation LePUS for "Language for Pattern Uniform Specification" became because the precursor of this language was primarily concerned with design patterns.
Examples LePUS3 is particularly suitable for modelling large programs, design patterns, and object-oriented application frameworks. It is unsuitable for modelling non object-oriented programs, architectural styles, and undecidable and semi-decidable properties.
The Closable inheritance hierarchy, The Factory method package java.io in LePUS3 pattern in LePUS3 The Enterprise JavaBeans in LePUS3
Unified Modeling Language
A collage of UML diagrams. Unified Modeling Language (UML) is a standardized general-purpose modeling language in the field of software engineering. UML includes a set of graphical notation techniques to create abstract models of specific systems.
Overview The Unified Modeling Language (UML) is an open method used to specify, visualize, modify, construct and document the artifacts of an object-oriented software intensive system under development. UML offers a standard way to write a system's blueprints, including conceptual components such as:
actors, business processes and system components and activities
as well as concrete things such as:
programming language statements, database schemas, and reusable software components.
UML combines best practices from data modeling concepts such as entity relationship diagrams, business modeling (work flow), object modeling and component modeling. It can be used with all processes, throughout the software development life cycle, and
across different implementation technologies. UML has succeeded the concepts of the Booch method, the Object-modeling technique (OMT) and Object-oriented software engineering (OOSE) by fusing them into a single, common and widely usable modeling language. UML aims to be a standard modeling language which can model concurrent and distributed systems. UML is not an industry standard, but is taking shape under the auspices of the Object Management Group (OMG). OMG has initially called for information on object-oriented methodologies, that might create a rigorous software modeling language. Many industry leaders have responded in earnest to help create the standard. UML models may be automatically transformed to other representations (e.g. Java) by means of QVT-like transformation languages, supported by the OMG. UML is extensible, offering the following mechanisms for customization: profiles and stereotype. The semantics of extension by profiles have been improved with the UML 1.0 major revision.
History
History of object-oriented methods and notation.
Before UML 1.x After Rational Software Corporation hired James Rumbaugh from General Electric in 1994, the company became the source for the two most popular object-oriented modeling approaches of the day: Rumbaugh's OMT, which was better for object-oriented analysis (OOA), and Grady Booch's Booch method, which was better for object-oriented design (OOD). Together Rumbaugh and Booch attempted to reconcile their two approaches and started work on a Unified Method. They were soon assisted in their efforts by Ivar Jacobson, the creator of the objectoriented software engineering (OOSE) method. Jacobson joined Rational in 1995, after his company, Objectory AB, was acquired by Rational. The three methodologists were
collectively referred to as the Three Amigos, since they were well known to argue frequently with each other regarding methodological practices. In 1996 Rational concluded that the abundance of modeling languages was slowing the adoption of object technology, so repositioning the work on a unified method, they tasked the Three Amigos with the development of a non-proprietary Unified Modeling Language. Representatives of competing object technology companies were consulted during OOPSLA '96; they chose boxes for representing classes over Grady Booch's Booch method's notation that used cloud symbols. Under the technical leadership of the Three Amigos, an international consortium called the UML Partners was organized in 1996 to complete the Unified Modeling Language (UML) specification, and propose it as a response to the OMG RFP. The UML Partners' UML 1.0 specification draft was proposed to the OMG in January 1997. During the same month the UML Partners formed a Semantics Task Force, chaired by Cris Kobryn and administered by Ed Eykholt, to finalize the semantics of the specification and integrate it with other standardization efforts. The result of this work, UML 1.1, was submitted to the OMG in August 1997 and adopted by the OMG in November 1997.
UML 1.x As a modeling notation, the influence of the OMT notation dominates (e. g., using rectangles for classes and objects). Though the Booch "cloud" notation was dropped, the Booch capability to specify lower-level design detail was embraced. The use case notation from Objectory and the component notation from Booch were integrated with the rest of the notation, but the semantic integration was relatively weak in UML 1.1, and was not really fixed until the UML 2.0 major revision. Concepts from many other OO methods were also loosely integrated with UML with the intent that UML would support all OO methods. For example CRC Cards (circa 1989 from Kent Beck and Ward Cunningham), and OORam were retained. Many others also contributed, with their approaches flavoring the many models of the day, including: Tony Wasserman and Peter Pircher with the "Object-Oriented Structured Design (OOSD)" notation (not a method), Ray Buhr's "Systems Design with Ada", Archie Bowen's use case and timing analysis, Paul Ward's data analysis and David Harel's "Statecharts"; as the group tried to ensure broad coverage in the real-time systems domain. As a result, UML is useful in a variety of engineering problems, from single process, single user applications to concurrent, distributed systems, making UML rich but also large. The Unified Modeling Language is an international standard: ISO/IEC 19501:2005 Information technology — Open Distributed Processing — Unified Modeling Language (UML) Version 1.4.2
Development toward UML 2.0
UML has matured significantly since UML 1.1. Several minor revisions (UML 1.3, 1.4, and 1.5) fixed shortcomings and bugs with the first version of UML, followed by the UML 2.0 major revision that was adopted by the OMG in 2005. There are four parts to the UML 2.x specification: 1. the Superstructure that defines the notation and semantics for diagrams and their model elements; 2. the Infrastructure that defines the core metamodel on which the Superstructure is based; 3. the Object Constraint Language (OCL) for defining rules for model elements; 4. and the UML Diagram Interchange that defines how UML 2 diagram layouts are exchanged. The current versions of these standards follow: UML Superstructure version 2.2, UML Infrastructure version 2.2, OCL version 2.0, and UML Diagram Interchange version 1.0. Although many UML tools support some of the new features of UML 2.x, the OMG provides no test suite to objectively test compliance with its specifications.
Unified Modeling Language topics Software Development Methods UML is not a development method by itself, however, it was designed to be compatible with the leading object-oriented software development methods of its time (for example OMT, Booch method, Objectory). Since UML has evolved, some of these methods have been recast to take advantage of the new notations (for example OMT), and new methods have been created based on UML. The best known is IBM Rational Unified Process (RUP). There are many other UML-based methods like Abstraction Method, Dynamic Systems Development Method, and others, designed to provide more specific solutions, or achieve different objectives.
Modeling It is very important to distinguish between the UML model and the set of diagrams of a system. A diagram is a partial graphical representation of a system's model. The model also contains a "semantic backplane" — documentation such as written use cases that drive the model elements and diagrams. UML diagrams represent two different views of a system model:
Static (or structural) view: Emphasizes the static structure of the system using objects, attributes, operations and relationships. The structural view includes class diagrams and composite structure diagrams.
Dynamic (or behavioral) view: Emphasizes the dynamic behavior of the system by showing collaborations among objects and changes to the internal states of objects. This view includes sequence diagrams, activity diagrams and state machine diagrams.
UML models can be exchanged among UML tools by using the XMI interchange format.
Diagrams overview UML 2.0 has 13 types of diagrams divided into three categories. Six diagram types represent the structure application, seven represent general types of behavior, including four that represent different aspects of interactions. UML does not restrict UML element types to a certain diagram type. In general, every UML element may appear on almost all types of diagrams. This flexibility has been partially restricted in UML 2.0. In keeping with the tradition of engineering drawings, a comment or note explaining usage, constraint, or intent is allowed in a UML diagram.
Structure diagrams Structure diagrams emphasize what things must be in the system being modeled:
Class diagram: describes the structure of a system by showing the system's classes, their attributes, and the relationships among the classes. Component diagram: depicts how a software system is split up into components and shows the dependencies among these components. Composite structure diagram: describes the internal structure of a class and the collaborations that this structure makes possible. Deployment diagram: serves to model the hardware used in system implementations, and the execution environments and artifacts deployed on the hardware. Object diagram: shows a complete or partial view of the structure of a modeled system at a specific time. Package diagram: depicts how a system is split up into logical groupings by showing the dependencies among these groupings.
Class diagram
Component diagram
Composite structure diagrams Deployment diagram
Object diagram
Package diagram
Since structure diagrams represent the structure of a system, they are used extensively in documenting the architecture of software systems.
Behavior diagrams Behavior diagrams emphasize what must happen in the system being modeled:
Activity diagram: represents the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control. State machine diagram: standardized notation to describe many systems, from computer programs to business processes. Use case diagram: shows the functionality provided by a system in terms of actors, their goals represented as use cases, and any dependencies among those use cases.
State Machine diagram UML Activity Diagram
Use case diagram
Since behaviour diagrams illustrate the behaviour of system, they are used extensively to describe the functionality of software systems.
Interaction diagrams Interaction diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled:
Communication diagram: shows the interactions between objects or parts in terms of sequenced messages. They represent a combination of information taken from Class, Sequence, and Use Case Diagrams describing both the static structure and dynamic behavior of a system. Interaction overview diagram: are a type of activity diagram in which the nodes represent interaction diagrams. Sequence diagram: shows how objects communicate with each other in terms of a sequence of messages. Also indicates the lifespans of objects relative to those messages.
Timing diagrams: are a specific type of interaction diagram, where the focus is on timing constraints.
The Protocol State Machine is a sub-variant of the State Machine. It may be used to model network communication protocols.
Meta modeling The Object Management Group (OMG) has developed a metamodeling architecture to define the Unified Modeling Language (UML), called the Meta-Object Facility (MOF). The Meta-Object Facility is a standard for model-driven engineering, designed as a fourlayered architecture, see image. It provides a meta-meta model at the top layer, called the M3 layer. This M3-model is the language used by Meta-Object Facility to build metamodels, called M2-models. The most prominent example of a Layer 2 Meta-Object Facility model is the UML metamodel, the model that describes the UML itself. These M2-models describe elements of the M1-layer, and thus M1-models. These would be, for example, models written in UML. The last layer is the M0-layer or data layer. It is used to describe real-world objects. Beyond the M3-model, the Meta-Object Facility describes the means to create and manipulate models and metamodels by defining CORBA interfaces that describe those operations. Because of the similarities between the Meta-Object Facility M3-model and UML structure models, Meta-Object Facility metamodels are usually modeled as UML class diagrams. A supporting standard of Meta-Object Facility is XMI, which defines an XML-based exchange format for models on the M3-, M2-, or M1-Layer.
Criticisms Although UML is a widely recognized and used modeling standard, it is frequently criticized for the following deficiencies: Language bloat Bertrand Meyer, in a satirical essay framed as a student's request for a grade change, apparently criticized UML as of 1997 for being unnecessarily large; a disclaimer was added later pointing out that his company nevertheless supports UML. Ivar Jacobson, a co-architect of UML, said that objections to UML 2.0's size were valid enough to consider the application of intelligent agents to the problem. It contains many diagrams and constructs that are redundant or infrequently used. Problems in learning and adopting The problems cited above can make learning and adopting UML problematic, especially when required of engineers lacking the prerequisite skills. In practice, people often draw diagrams with the symbols provided by their CASE tool, but without the meanings those symbols are intended to provide. Cumulative Impedance/Impedance Mismatching
As with any notational system, UML is able to represent some systems more concisely or efficiently than others. Thus a developer gravitates toward solutions that reside at the intersection of the capabilities of UML and the implementation language. This problem is particularly pronounced if the implementation language does not adhere to orthodox object-oriented doctrine, as the intersection set between UML and implementation language may be that much smaller. Dysfunctional interchange format While the XMI (XML Metadata Interchange) standard is designed to facilitate the interchange of UML models, it has been largely ineffective in the practical interchange of UML 2.x models. This interoperability ineffectiveness is attributable to two reasons. Firstly, XMI 2.x is large and complex in its own right, since it purports to address a technical problem more ambitious than exchanging UML 2.x models. In particular, it attempts to provide a mechanism for facilitating the exchange of any arbitrary modeling language defined by the OMG's MetaObject Facility (MOF). Secondly, the UML 2.x Diagram Interchange specification lacks sufficient detail to facilitate reliable interchange of UML 2.x notations between modeling tools. Since UML is a visual modeling language, this shortcoming is substantial for modelers who don't want to redraw their diagrams. Modeling experts have written sharp criticisms of UML, including Bertrand Meyer's "UML: The Positive Spin", and Brian Henderson-Sellers in "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0".
Chapter-3
Software development & Software Testing
Software development process Activities and steps Requirements · Specification Architecture · Design Implementation · Testing Deployment · Maintenance Models Agile · Cleanroom · DSDM Iterative · RAD · RUP · Spiral Waterfall · XP · Scrum · Lean V-Model · FDD Supporting disciplines Configuration management Documentation Quality assurance (SQA) Project management User experience design Tools
Compiler · Debugger · Profiler GUI designer Integrated development environment
Software development is the set of activities that results in software products. Software development may include research, new development, modification, reuse, reengineering, maintenance, or any other activities that result in software products. Especially the first phase in the software development process may involve many departments, including marketing, engineering, research and development and general management. The term software development may also refer to computer programming, the process of writing and maintaining the source code.
Overview There are several different approaches to software development, much like the various views of political parties toward governing a country. Some take a more structured, engineering-based approach to developing business solutions, whereas others may take a more incremental approach, where software evolves as it is developed piece-by-piece. Most methodologies share some combination of the following stages of software development:
Market research Gathering requirements for the proposed business solution Analyzing the problem Devising a plan or design for the software-based solution Implementation (coding) of the software Testing the software Deployment Maintenance and bug fixing
These stages are often referred to collectively as the software development lifecycle, or SDLC. Different approaches to software development may carry out these stages in different orders, or devote more or less time to different stages. The level of detail of the documentation produced at each stage of software development may also vary. These stages may also be carried out in turn (a “waterfall” based approach), or they may be repeated over various cycles or iterations (a more "extreme" approach). The more extreme approach usually involves less time spent on planning and documentation, and more time spent on coding and development of automated tests. More “extreme” approaches also promote continuous testing throughout the development lifecycle, as
well as having a working (or bug-free) product at all times. More structured or “waterfall” based approaches attempt to assess the majority of risks and develop a detailed plan for the software before implementation (coding) begins, and avoid significant design changes and re-coding in later stages of the software development lifecycle. There are significant advantages and disadvantages to the various methodologies, and the best approach to solving a problem using software will often depend on the type of problem. If the problem is well understood and a solution can be effectively planned out ahead of time, the more "waterfall" based approach may work the best. If, on the other hand, the problem is unique (at least to the development team) and the structure of the software solution cannot be easily envisioned, then a more "extreme" incremental approach may work best. A software development process is a structure imposed on the development of a software product. Synonyms include software life cycle and software process. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process.
Software development topics Marketing The sources of ideas for software products are legion. These ideas can come from market research including the demographics of potential new customers, existing customers, sales prospects who rejected the product, other internal software development staff, or a creative third party. Ideas for software products are usually first evaluated by marketing personnel for economic feasibility, for fit with existing channels distribution, for possible effects on existing product lines, required features, and for fit with the company's marketing objectives. In a marketing evaluation phase, the cost and time assumptions become evaluated. A decision is reached early in the first phase as to whether, based on the more detailed information generated by the marketing and development staff, the project should be pursued further. In the book "Great Software Debates", Alan M. Davis states in the chapter "Requirements", subchapter "The Missing Piece of Software Development":
“
Students of engineering learn engineering and are rarely exposed to finance or marketing. Students of marketing learn marketing and are rarely exposed to finance or engineering. Most of us become specialists in just one area. To complicate matters, few of us meet interdisciplinary people in the workforce, so there are few roles to mimic. Yet, software product planning is critical to the development success and absolutely requires knowledge of multiple disciplines.
Because software development may involve compromising or going beyond what is required by the client, a software development project may stray into less technical concerns such as human resources, risk management, intellectual property, budgeting,
”
crisis management, etc. These processes may also cause the role of business development to overlap with software development.
Software development methodology A software development methodology is a framework that is used to structure, plan, and control the process of developing information systems. A wide variety of such frameworks have evolved over the years, each with its own recognized strengths and weaknesses. One system development methodology is not necessarily suitable for use by all projects. Each of the available methodologies is best suited to specific kinds of projects, based on various technical, organizational, project and team considerations.
Recent trends in the sector Given the rapid growth of this sector, several companies have started to use offshore development in China, India and other countries with a lower cost per developer model. Several new Web 2.0 platforms and sites are now developed offshore while management is located in Western countries. The advantages mostly revolve around better cost-control over the process, which means that there is lower cash-outflow (often the biggest struggle for startups). Furthermore, the time difference when working with India and China for the Western world allows work to be done round the clock adding a competitive advantage. Notable firms that are involved in development include Tata Consultancy Services, Infosys, Wipro, and Satyam.
Software testing Software Testing is an empirical investigation conducted to provide stakeholders with information about the quality of the product or service under test, with respect to the context in which it is intended to operate. Software Testing also provides an objective, independent view of the software to allow the business to appreciate and understand the risks at implementation of the software. Test techniques include, but are not limited to, the process of executing a program or application with the intent of finding software bugs. Software Testing can also be stated as the process of validating and verifying that a software program/application/product (1) meets the business and technical requirements that guided its design and development; (2) works as expected; and (3) can be implemented with the same characteristics. Software Testing, depending on the testing method employed, can be implemented at any time in the development process, however most of the test effort occurs after the requirements have been defined and the coding process has been completed.
Overview
Testing can never completely identify all the defects within software. Instead, it furnishes a criticism or comparison that compares the state and behavior of the product against oracles—principles or mechanisms by which someone might recognize a problem. These oracles may include (but are not limited to) specifications, contracts, comparable products, past versions of the same product, inferences about intended or expected purpose, user or customer expectations, relevant standards, applicable laws, or other criteria. Every software product has a target audience. For example, the audience for video game software is completely different from banking software. Therefore, when an organization develops or otherwise invests in a software product, it can assess whether the software product will be acceptable to its end users, its target audience, its purchasers, and other stakeholders. Software testing is the process of attempting to make this assessment. A study conducted by NIST in 2002 reports that software bugs cost the U.S. economy $59.5 billion annually. More than a third of this cost could be avoided if better software testing was performed.
History The separation of debugging from testing was initially introduced by Glenford J. Myers in 1979. Although his attention was on breakage testing ("a successful test is one that finds a bug"), it illustrated the desire of the software engineering community to separate fundamental development activities, such as debugging, from that of verification. Dave Gelperin and William C. Hetzel classified in 1988 the phases and goals in software testing in the following stages:
Until 1956 - Debugging oriented 1957–1978 - Demonstration oriented 1979–1982 - Destruction oriented 1983–1987 - Evaluation oriented 1988–2000 - Prevention oriented
Software testing topics Scope A primary purpose for testing is to detect software failures so that defects may be uncovered and corrected. This is a non-trivial pursuit. Testing cannot establish that a product functions properly under all conditions but can only establish that it does not function properly under specific conditions. The scope of software testing often includes examination of code as well as execution of that code in various environments and conditions as well as examining the aspects of code: does it do what it is supposed to do and do what it needs to do. In the current culture of software development, a testing organization may be separate from the development team. There are various roles for
testing team members. Information derived from software testing may be used to correct the process by which software is developed.
Defects and failures Not all software defects are caused by coding errors. One common source of expensive defects is caused by requirement gaps, e.g., unrecognized requirements, that result in errors of omission by the program designer. A common source of requirements gaps is non-functional requirements such as testability, scalability, maintainability, usability, performance, and security. Software faults occur through the following processes. A programmer makes an error (mistake), which results in a defect (fault, bug) in the software source code. If this defect is executed, in certain situations the system will produce wrong results, causing a failure. Not all defects will necessarily result in failures. For example, defects in dead code will never result in failures. A defect can turn into a failure when the environment is changed. Examples of these changes in environment include the software being run on a new hardware platform, alterations in source data or interacting with different software. A single defect may result in a wide range of failure symptoms.
Compatibility A frequent cause of software failure is compatibility with another application, a new operating system, or, increasingly, web browser version. In the case of lack of backward compatibility, this can occur (for example...) because the programmers have only considered coding their programs for, or testing the software upon, "the latest version of" this-or-that operating system. The unintended consequence of this fact is that: their latest work might not be fully compatible with earlier mixtures of software/hardware, or it might not be fully compatible with another important operating system. In any case, these differences, whatever they might be, may have resulted in (unintended...) software failures, as witnessed by some significant population of computer users. This could be considered a "prevention oriented strategy" that fits well with the latest testing phase suggested by Dave Gelperin and William C. Hetzel, as cited below .
Input combinations and preconditions A very fundamental problem with software testing is that testing under all combinations of inputs and preconditions (initial state) is not feasible, even with a simple product. This means that the number of defects in a software product can be very large and defects that occur infrequently are difficult to find in testing. More significantly, non-functional dimensions of quality (how it is supposed to be versus what it is supposed to do)— usability, scalability, performance, compatibility, reliability—can be highly subjective; something that constitutes sufficient value to one person may be intolerable to another.
Static vs. dynamic testing
There are many approaches to software testing. Reviews, walkthroughs, or inspections are considered as static testing, whereas actually executing programmed code with a given set of test cases is referred to as dynamic testing. Static testing can be (and unfortunately in practice often is) omitted. Dynamic testing takes place when the program itself is used for the first time (which is generally considered the beginning of the testing stage). Dynamic testing may begin before the program is 100% complete in order to test particular sections of code (modules or discrete functions). Typical techniques for this are either using stubs/drivers or execution from a debugger environment. For example, Spreadsheet programs are, by their very nature, tested to a large extent interactively ("on the fly"), with results displayed immediately after each calculation or text manipulation.
Software verification and validation Software testing is used in association with verification and validation:
Verification: Have we built the software right? (i.e., does it match the specification). Validation: Have we built the right software? (i.e., is this what the customer wants).
The terms verification and validation are commonly used interchangeably in the industry; it is also common to see these two terms incorrectly defined. According to the IEEE Standard Glossary of Software Engineering Terminology: Verification is the process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. Validation is the process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements.
The software testing team Software testing can be done by software testers. Until the 1980s the term "software tester" was used generally, but later it was also seen as a separate profession. Regarding the periods and the different goals in software testing, different roles have been established: manager, test lead, test designer, tester, automation developer, and test administrator.
Software Quality Assurance (SQA) Though controversial, software testing may be viewed as an important part of the software quality assurance (SQA) process. In SQA, software process specialists and auditors take a broader view on software and its development. They examine and change the software engineering process itself to reduce the amount of faults that end up in the delivered software: the so-called defect rate.
What constitutes an "acceptable defect rate" depends on the nature of the software. For example, an arcade video game designed to simulate flying an airplane would presumably have a much higher tolerance for defects than mission critical software such as that used to control the functions of an airliner that really is flying! Although there are close links with SQA, testing departments often exist independently, and there may be no SQA function in some companies. Software Testing is a task intended to detect defects in software by contrasting a computer program's expected results with its actual results for a given set of inputs. By contrast, QA (Quality Assurance) is the implementation of policies and procedures intended to prevent defects from occurring in the first place.
Testing methods Approach of boxes Software testing methods are traditionally divided into black box testing and white box testing. These two approaches are used to describe the point of view that a test engineer takes when designing test cases. Black box testing Black box testing treats the software as a "black box"—without any knowledge of internal implementation. Black box testing methods include: equivalence partitioning, boundary value analysis, all-pairs testing, fuzz testing, model-based testing, traceability matrix, exploratory testing and specification-based testing. Specification-based testing: Specification-based testing aims to test the functionality of software according to the applicable requirements. Thus, the tester inputs data into, and only sees the output from, the test object. This level of testing usually requires thorough test cases to be provided to the tester, who then can simply verify that for a given input, the output value (or behavior), either "is" or "is not" the same as the expected value specified in the test case. Specification-based testing is necessary, but it is insufficient to guard against certain risks. Advantages and disadvantages: The black box tester has no "bonds" with the code, and a tester's perception is very simple: a code must have bugs. Using the principle, "Ask and you shall receive," black box testers find bugs where programmers do not. But, on the other hand, black box testing has been said to be "like a walk in a dark labyrinth without a flashlight," because the tester doesn't know how the software being tested was actually constructed. As a result, there are situations when (1) a tester writes many test cases to check something that could have been tested by only one test case, and/or (2) some parts of the backend are not tested at all.
Therefore, black box testing has the advantage of "an unaffiliated opinion," on the one hand, and the disadvantage of "blind exploring," on the other. White box testing White box testing is when the tester has access to the internal data structures and algorithms including the code that implement these. Types of white box testing The following types of white box testing exist:
API testing (application programming interface) - Testing of the application using Public and Private APIs Code coverage - creating tests to satisfy some criteria of code coverage (e.g., the test designer can create tests to cause all statements in the program to be executed at least once) Fault injection methods Mutation testing methods Static testing - White box testing includes all static testing
Code completeness evaluation White box testing methods can also be used to evaluate the completeness of a test suite that was created with black box testing methods. This allows the software team to examine parts of a system that are rarely tested and ensures that the most important function points have been tested. Two common forms of code coverage are:
Function coverage, which reports on functions executed Statement coverage, which reports on the number of lines executed to complete the test
They both return a code coverage metric, measured as a percentage. Grey Box Testing Grey box testing involves having access to internal data structures and algorithms for purposes of designing the test cases, but testing at the user, or black-box level. Manipulating input data and formatting output do not qualify as grey box, because the input and output are clearly outside of the "black-box" that we are calling the system under test. This distinction is particularly important when conducting integration testing between two modules of code written by two different developers, where only the interfaces are exposed for test. However, modifying a data repository does qualify as grey box, as the user would not normally be able to change the data outside of the system under test. Grey box testing may also include reverse engineering to determine, for instance, boundary values or error messages.
Integration Testing Integration testing Integration testing is any type of software testing, that seeks to uncover collisions of individual software modules to each other. Such integration defects can arise, when the new modules are developed in separate branches, and then integrated into the main project.
Regression Testing Regression testing Regression testing is any type of software testing, that seeks to uncover software regressions. Such regression occur whenever software functionality, that was previously working correctly, stops working as intended. Typically, regressions occur as an unintended consequence of program changes, when the newly developed part of the software collides with the previously existing. Common methods of regression testing include re-running previously run tests and checking whether previously fixed faults have re-emerged. The depth of testing depends on the phase in the release process and the risk of the added features. They can either be complete, for changes added late in the release or deemed to be risky, to very shallow, consisting of positive tests on each feature, if the changes are early in the release or deemed to be of low risk.
Acceptance testing Acceptance testing Acceptance testing can mean one of two things: 1. A smoke test is used as an acceptance test prior to introducing a new build to the main testing process, i.e. before integration or regression. 2. Acceptance testing performed by the customer, often in their lab environment on their own HW, is known as user acceptance testing (UAT).
Non Functional Software Testing Special methods exist to test non-functional aspects of software.
Performance testing checks to see if the software can handle large quantities of data or users. This is generally referred to as software scalability. This activity of Non Functional Software Testing is often referred to as Endurance Testing. Stability testing checks to see if the software can continuously function well in or above an acceptable period. This activity of Non Functional Software Testing is oftentimes referred to as load (or endurance) testing.
Usability testing is needed to check if the user interface is easy to use and understand. Security testing is essential for software that processes confidential data to prevent system intrusion by hackers. Internationalization and localization is needed to test these aspects of software, for which a pseudolocalization method can be used.
In contrast to functional testing, which establishes the correct operation of the software (correct in that it matches the expected behavior defined in the design requirements), nonfunctional testing verifies that the software functions properly even when it receives invalid or unexpected inputs. Software fault injection, in the form of fuzzing, is an example of non-functional testing. Non-functional testing, especially for software, is designed to establish whether the device under test can tolerate invalid or unexpected inputs, thereby establishing the robustness of input validation routines as well as errorhandling routines. Various commercial non-functional testing tools are linked from the Software fault injection page; there are also numerous open-source and free software tools available that perform non-functional testing..
Destructive testing Destructive testing attempts to cause the software or a sub-system to fail, in order to test its robustness.
Testing process A common practice of software testing is performed by an independent group of testers after the functionality is developed before it is shipped to the customer. This practice often results in the testing phase being used as project buffer to compensate for project delays, thereby compromising the time devoted to testing. Another practice is to start software testing at the same moment the project starts and it is a continuous process until the project finishes. In counterpoint, some emerging software disciplines such as extreme programming and the agile software development movement, adhere to a "test-driven software development" model. In this process, unit tests are written first, by the software engineers (often with pair programming in the extreme programming methodology). Of course these tests fail initially; as they are expected to. Then as code is written it passes incrementally larger portions of the test suites. The test suites are continuously updated as new failure conditions and corner cases are discovered, and they are integrated with any regression tests that are developed. Unit tests are maintained along with the rest of the software source code and generally integrated into the build process (with inherently interactive tests being relegated to a partially manual build acceptance process). Testing can be done on the following levels:
Unit testing tests the minimal software component, or module. Each unit (basic component) of the software is tested to verify that the detailed design for the unit has been correctly implemented. In an object-oriented environment, this is usually at the class level, and the minimal unit tests include the constructors and destructors. Integration testing exposes defects in the interfaces and interaction between integrated components (modules). Progressively larger groups of tested software components corresponding to elements of the architectural design are integrated and tested until the software works as a system. System testing tests a completely integrated system to verify that it meets its requirements. System integration testing verifies that a system is integrated to any external or third party systems defined in the system requirements.
Before shipping the final version of software, alpha and beta testing are often done additionally:
Alpha testing is simulated or actual operational testing by potential users/customers or an independent test team at the developers' site. Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing, before the software goes to beta testing. Beta testing comes after alpha testing. Versions of the software, known as beta versions, are released to a limited audience outside of the programming team. The software is released to groups of people so that further testing can ensure the product has few faults or bugs. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users.
Finally, acceptance testing can be conducted by the end-user, customer, or client to validate whether or not to accept the product. Acceptance testing may be performed as part of the hand-off process between any two phases of development.
Regression testing Regression testing After modifying software, either for a change in functionality or to fix defects, a regression test re-runs previously passing tests on the modified software to ensure that the modifications have not unintentionally caused a regression of previous functionality. Regression testing can be performed at any or all of the above test levels. These regression tests are often automated. More specific forms of regression testing are known as sanity testing (which quickly checks for bizarre behavior) and smoke testing (which tests for basic functionality).
Benchmarks may be employed during regression testing to ensure that the performance of the newly modified software will be at least as acceptable as the earlier version or, in the case of code optimization, that some real improvement has been achieved.
Finding faults Finding faults early It is commonly believed that the earlier a defect is found the cheaper it is to fix it. The following table shows the cost of fixing the defect depending on the stage it was found. For example, if a problem in the requirements is found only post-release, then it would cost 10–100 times more to fix than if it had already been found by the requirements review.
Time Detected
Requirements Architecture Construction
1×
3×
5–10×
10×
10– 100×
Time Introduced Architecture
-
1×
10×
15×
25– 100×
Construction
-
-
1×
10×
10–25×
Requirements
Testing Tools Test automation Program testing and fault detection can be aided significantly by testing tools and debuggers. Testing/debug tools include features such as:
System PostTest Release
Program monitors, permitting full or partial monitoring of program code including: o Instruction Set Simulator, permitting complete instruction level monitoring and trace facilities
Program animation, permitting step-by-step execution and conditional breakpoint at source level or in machine code o Code coverage reports Formatted dump or Symbolic debugging, tools allowing inspection of program variables on error or at chosen points Automated functional GUI testing tools are used to repeat system-level tests through the GUI Benchmarks, allowing run-time performance comparisons to be made Performance analysis (or profiling tools) that can help to highlight hot spots and resource usage o
Some of these features may be incorporated into an Integrated Development Environment (IDE).
Measuring software testing Usually, quality is constrained to such topics as correctness, completeness, security, but can also include more technical requirements as described under the ISO standard ISO 9126, such as capability, reliability, efficiency, portability, maintainability, compatibility, and usability. There are a number of common software measures, often called "metrics", which are used to measure the state of the software or the adequacy of the testing.
Testing artifacts Software testing process can produce several artifacts. Test plan A test specification is called a test plan. The developers are well aware what test plans will be executed and this information is made available to management and the developers. The idea is makes them more cautious when developing their code or making additional changes. Some companies have a higher-level document called a test strategy. Traceability matrix A traceability matrix is a table that correlates requirements or design documents to test documents. It is used to change tests when the source documents are changed, or to verify that the test results are correct. Test case A test case normally consists of a unique identifier, requirement references from a design specification, preconditions, events, a series of steps (also known as actions) to follow, input, output, expected result, and actual result. Clinically defined a test case is an input and an expected result. This can be as pragmatic as 'for condition x your derived result is y', whereas other test cases described in more detail the input scenario and what results might be expected. It can occasionally be a series of steps (but often steps are contained in a separate test
procedure that can be exercised against multiple test cases, as a matter of economy) but with one expected result or expected outcome. The optional fields are a test case ID, test step, or order of execution number, related requirement(s), depth, test category, author, and check boxes for whether the test is automatable and has been automated. Larger test cases may also contain prerequisite states or steps, and descriptions. A test case should also contain a place for the actual result. These steps can be stored in a word processor document, spreadsheet, database, or other common repository. In a database system, you may also be able to see past test results, who generated the results, and what system configuration was used to generate those results. These past results would usually be stored in a separate table. Test script The test script is the combination of a test case, test procedure, and test data. Initially the term was derived from the product of work created by automated regression test tools. Today, test scripts can be manual, automated, or a combination of both. Test suite The most common term for a collection of test cases is a test suite. The test suite often also contains more detailed instructions or goals for each collection of test cases. It definitely contains a section where the tester identifies the system configuration used during testing. A group of test cases may also contain prerequisite states or steps, and descriptions of the following tests. Test data In most cases, multiple sets of values or data are used to test the same functionality of a particular feature. All the test values and changeable environmental components are collected in separate files and stored as test data. It is also useful to provide this data to the client and with the product or a project. Test harness The software, tools, samples of data input and output, and configurations are all referred to collectively as a test harness.
A sample testing cycle Although variations exist between organizations, there is a typical cycle for testing:
Requirements analysis: Testing should begin in the requirements phase of the software development life cycle. During the design phase, testers work with developers in determining what aspects of a design are testable and with what parameters those tests work. Test planning: Test strategy, test plan, testbed creation. Since many activities will be carried out during testing, a plan is needed. Test development: Test procedures, test scenarios, test cases, test datasets, test scripts to use in testing software. Test execution: Testers execute the software based on the plans and tests and report any errors found to the development team.
Test reporting: Once testing is completed, testers generate metrics and make final reports on their test effort and whether or not the software tested is ready for release. Test result analysis: Or Defect Analysis, is done by the development team usually along with the client, in order to decide what defects should be treated, fixed, rejected (i.e. found software working properly) or deferred to be dealt with later. Defect Retesting: Once a defect has been dealt with by the development team, it is retested by the testing team. Regression testing: It is common to have a small test program built of a subset of tests, for each integration of new, modified, or fixed software, in order to ensure that the latest delivery has not ruined anything, and that the software product as a whole is still working correctly. Test Closure: Once the test meets the exit criteria, the activities such as capturing the key outputs, lessons learned, results, logs, documents related to the project are archived and used as a reference for future projects.
Certifications Several certification programs exist to support the professional aspirations of software testers and quality assurance specialists. No certification currently offered actually requires the applicant to demonstrate the ability to test software. No certification is based on a widely accepted body of knowledge. This has led some to declare that the testing field is not ready for certification. Certification itself cannot measure an individual's productivity, their skill, or practical knowledge, and cannot guarantee their competence, or professionalism as a tester. Software testing certification types
Exam-based: Formalized exams, which need to be passed; can also be learned by self-study [e.g., for ISTQB or QAI] Education-based: Instructor-led sessions, where each course has to be passed [e.g., International Institute for Software Testing (IIST)].
Testing certifications
CATe offered by the International Institute for Software Testing Certified Software Tester (CSTE) offered by the Quality Assurance Institute (QAI) Certified Software Test Professional (CSTP) offered by the International Institute for Software Testing CSTP (TM) (Australian Version) offered by K. J. Ross & Associates ISEB offered by the Information Systems Examinations Board ISTQB Certified Tester, Foundation Level (CTFL) offered by the International Software Testing Qualification Board
ISTQB Certified Tester, Advanced Level (CTAL) offered by the International Software Testing Qualification Board TMPF TMap Next Foundation offered by the Examination Institute for Information Science
Quality assurance certifications
CSQE offered by the American Society for Quality (ASQ) CSQA offered by the Quality Assurance Institute (QAI) CQIA offered by the American Society for Quality (ASQ) CMSQ offered by the Quality Assurance Institute (QAI)
Controversy Some of the major software testing controversies include: What constitutes responsible software testing? Members of the "context-driven" school of testing believe that there are no "best practices" of testing, but rather that testing is a set of skills that allow the tester to select or invent testing practices to suit each unique situation. Agile vs. traditional Should testers learn to work under conditions of uncertainty and constant change or should they aim at process "maturity"? The agile testing movement has received growing popularity since 2006 mainly in commercial circles , whereas government and military software providers are slow to embrace this methodology, and mostly still hold to CMMI. Exploratory test vs. scripted Should tests be designed at the same time as they are executed or should they be designed beforehand? Manual testing vs. automated Some writers believe that test automation is so expensive relative to its value that it should be used sparingly. Others, such as advocates of agile development, recommend automating 100% of all tests. More in particular, test-driven development states that developers should write unit-tests of the XUnit type before coding the functionality. The tests then can be considered as a way to capture and implement the requirements. Software design vs. software implementation Should testing be carried out only at the end or throughout the whole process? Who watches the watchmen? The idea is that any form of observation is also an interaction—the act of testing can also affect that which is being tested.
Chapter-4
Software development process, Computer-aided Software engineering Software quality
Software development process A software development process is a structure imposed on the development of a software product. Synonyms include software life cycle and software process. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process.
Overview The largely growing body of software development organizations implement process methodologies. Many of them are in the defense industry, which in the U.S. requires a rating based on 'process models' to obtain contracts. The international standard for describing the method of selecting, implementing and monitoring the life cycle for software is ISO 12207. A decades-long goal has been to find repeatable, predictable processes that improve productivity and quality. Some try to systematize or formalize the seemingly unruly task of writing software. Others apply project management techniques to writing software. Without project management, software projects can easily be delivered late or over budget. With large numbers of software projects not meeting their expectations in terms of functionality, cost, or delivery schedule, effective project management appears to be lacking. Organizations may create a Software Engineering Process Group (SEPG), which is the focal point for process improvement. Composed of line practitioners who have varied skills, the group is at the center of the collaborative effort of everyone in the organization who is involved with software engineering process improvement.
Software development activities The activities of the software development process represented in the waterfall model. There are several other models to represent this process.
Planning The important task in creating a software product is extracting the requirements or requirements analysis. Customers typically have an abstract idea of what they want as an end result, but not what software should do. Incomplete, ambiguous, or even contradictory requirements are recognized by skilled and experienced software engineers at this point. Frequently demonstrating live code may help reduce the risk that the requirements are incorrect. Once the general requirements are gleaned from the client, an analysis of the scope of the development should be determined and clearly stated. This is often called a scope document. Certain functionality may be out of scope of the project as a function of cost or as a result of unclear requirements at the start of development. If the development is done externally, this document can be considered a legal document so that if there are ever disputes, any ambiguity of what was promised to the client can be clarified.
Design Domain Analysis is often the first step in attempting to design a new piece of software, whether it be an addition to an existing software, a new application, a new subsystem or a whole new system. Assuming that the developers (including the analysts) are not sufficiently knowledgeable in the subject area of the new software, the first task is to investigate the so-called "domain" of the software. The more knowledgeable they are about the domain already, the less work required. Another objective of this work is to make the analysts, who will later try to elicit and gather the requirements from the area experts, speak with them in the domain's own terminology, facilitating a better understanding of what is being said by these experts. If the analyst does not use the proper terminology it is likely that they will not be taken seriously, thus this phase is an important prelude to extracting and gathering the requirements. If an analyst hasn't done the appropriate work confusion may ensue: "I know you believe you understood what you think I said, but I am not sure you realize what you heard is not what I meant."
Specification Specification is the task of precisely describing the software to be written, possibly in a rigorous way. In practice, most successful specifications are written to understand and fine-tune applications that were already well-developed, although safety-critical software systems are often carefully specified prior to application development. Specifications are most important for external interfaces that must remain stable. A good way to determine whether the specifications are sufficiently precise is to have a third party review the documents making sure that the requirements and Use Cases are logically sound.
Architecture The architecture of a software system or software architecture refers to an abstract representation of that system. Architecture is concerned with making sure the software
system will meet the requirements of the product, as well as ensuring that future requirements can be addressed. The architecture step also addresses interfaces between the software system and other software products, as well as the underlying hardware or the host operating system.
Implementation, testing and documenting Implementation is the part of the process where software engineers actually program the code for the project. Software testing is an integral and important part of the software development process. This part of the process ensures that bugs are recognized as early as possible. Documenting the internal design of software for the purpose of future maintenance and enhancement is done throughout development. This may also include the authoring of an API, be it external or internal.
Deployment and maintenance Deployment starts after the code is appropriately tested, is approved for release and sold or otherwise distributed into a production environment. Software Training and Support is important because a large percentage of software projects fail because the developers fail to realize that it doesn't matter how much time and planning a development team puts into creating software if nobody in an organization ends up using it. People are often resistant to change and avoid venturing into an unfamiliar area, so as a part of the deployment phase, it is very important to have training classes for new clients of your software. Maintenance and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software. It may be necessary to add code that does not fit the original design to correct an unforeseen problem or it may be that a customer is requesting more functionality and code can be added to accommodate their requests. It is during this phase that customer calls come in and you see whether your testing was extensive enough to uncover the problems before customers do. If the labor cost of the maintenance phase exceeds 25% of the prior-phases' labor cost, then it is likely that the overall quality, of at least one prior phase, is poor. In that case, management should consider the option of rebuilding the system (or portions) before maintenance cost is out of control. Bug Tracking System tools are often deployed at this stage of the process to allow development teams to interface with customer/field teams testing the software to identify any real or perceived issues. These software tools, both open source and commercially licensed, provide a customizable process to acquire, review, acknowledge, and respond to reported issues.
Models Iterative processes Iterative development prescribes the construction of initially small but ever larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster. Iterative processes are preferred by commercial developers because it allows a potential of reaching the design goals of a customer who does not know how to define what they want.
Agile software development Agile software development processes are built on the foundation of iterative development. To that foundation they add a lighter, more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software. Interestingly, surveys have shown the potential for significant efficiency gains over the waterfall method. For example, a survey, published in August 2006 by VersionOne and Agile Alliance and based on polling more than 700 companies claims the following benefits for an Agile approach. The survey was repeated in August 2007 with about 1,700 respondents.
XP: Extreme Programming Extreme Programming (XP) is the best-known iterative process. In XP, the phases are carried out in extremely small (or "continuous") steps compared to the older, "batch" processes. The (intentionally incomplete) first pass through the steps might take a day or a week, rather than the months or years of each complete step in the Waterfall model. First, one writes automated tests, to provide concrete goals for development. Next is coding (by a pair of programmers), which is complete when all the tests pass, and the programmers can't think of any more tests that are needed. Design and architecture emerge out of refactoring, and come after coding. Design is done by the same people who do the coding. (Only the last feature - merging design and code - is common to all the other agile processes.) The incomplete but functional system is deployed or demonstrated for (some subset of) the users (at least one of which is on the development team). At this point, the practitioners start again on writing tests for the next most important part of the system.
Waterfall processes The waterfall model shows a process, where developers are to follow these steps in order: 1. Requirements specification (AKA Verification or Analysis)
2. 3. 4. 5. 6. 7.
Design Construction (AKA implementation or coding) Integration Testing and debugging (AKA validation) Installation (AKA deployment) Maintenance
After each step is finished, the process proceeds to the next step, just as builders don't revise the foundation of a house after the framing has been erected. There is a misconception that the process has no provision for correcting errors in early steps (for example, in the requirements). In fact this is where the domain of requirements management comes in, which includes change control. The counter argument, by critics to the process, is the significantly increased cost in correcting problems through introduction of iterations. This is also the factor that extends delivery time and makes this process increasingly unpopular even in high risk projects. This approach is used in high risk projects, particularly large defense contracts. The problems in waterfall do not arise from "immature engineering practices, particularly in requirements analysis and requirements management." Studies of the failure rate of the DOD-STD-2167 specification, which enforced waterfall, have shown that the more closely a project follows its process, specifically in up-front requirements gathering, the more likely the project is to release features that are not used in their current form. Often the supposed stages are part of review between customer and supplier, the supplier can, in fact, develop at risk and evolve the design but must sell off the design at a key milestone called Critical Design Review (CDR). This shifts engineering burdens from engineers to customers who may have other skills.
Other models Capability Maturity Model Integration The Capability Maturity Model Integration (CMMI) is one of the leading models and based on best practice. Independent assessments grade organizations on how well they follow their defined processes, not on the quality of those processes or the software produced. CMMI has replaced CMM. ISO 9000 ISO 9000 describes standards for formally organizing processes with documentation. ISO 15504 ISO 15504, also known as Software Process Improvement Capability Determination (SPICE), is a "framework for the assessment of software processes". This standard is aimed at setting out a clear model for process comparison. SPICE is used much like CMMI. It models processes to manage, control, guide and monitor software development. This model is then used to measure what a development organization or project team actually does during
software development. This information is analyzed to identify weaknesses and drive improvement. It also identifies strengths that can be continued or integrated into common practice for that organization or team. Six sigma Six Sigma is a methodology to manage process variations that uses data and statistical analysis to measure and improve a company's operational performance. It works by identifying and eliminating defects in manufacturing and servicerelated processes. The maximum permissible defects is 3.4 per one million opportunities. However, Six Sigma is manufacturing-oriented and needs further research on its relevance to software development. Test Driven Development Test Driven Development (TDD) is a useful output of the Agile camp but some suggest that it raises a conundrum. TDD requires that a unit test be written for a class before the class is written. It might be thought, then, that the class firstly has to be "discovered" and secondly defined in sufficient detail to allow the write-testonce-and-code-until-class-passes model that TDD actually uses. This would be actually counter to Agile approaches, particularly (so-called) Agile Modeling, where developers are still encouraged to code early, with light design. However, to get the claimed benefits of TDD a full design down to class and responsibilities (captured using, for example, Design By Contract) is not necessary. This would count towards iterative development, with a design locked down, but not iterative design - as heavy refactoring and re-engineering might negate the usefulness of TDD.
Formal methods Formal methods are mathematical approaches to solving software (and hardware) problems at the requirements, specification and design levels. Examples of formal methods include the B-Method, Petri nets, Automated theorem proving, RAISE and VDM. Various formal specification notations are available, such as the Z notation. More generally, automata theory can be used to build up and validate application behavior by designing a system of finite state machines. Finite state machine (FSM) based methodologies allow executable software specification and by-passing of conventional coding (see virtual finite state machine or event driven finite state machine). Formal methods are most likely to be applied in avionics software, particularly where the software is safety critical. Software safety assurance standards, such as DO178B demand formal methods at the highest level of categorization (Level A). Formalization of software development is creeping in, in other places, with the application of Object Constraint Language (and specializations such as Java Modeling Language) and especially with Model-driven architecture allowing execution of designs, if not specifications.
Another emerging trend in software development is to write a specification in some form of logic (usually a variation of FOL), and then to directly execute the logic as though it were a program. The OWL language, based on Description Logic, is an example. There is also work on mapping some version of English (or another natural language) automatically to and from logic, and executing the logic directly. Examples are Attempto Controlled English, and Internet Business Logic, which does not seek to control the vocabulary or syntax. A feature of systems that support bidirectional English-logic mapping and direct execution of the logic is that they can be made to explain their results, in English, at the business or scientific level. The Government Accountability Office, in a 2003 report on one of the Federal Aviation Administration’s air traffic control modernization programs, recommends following the agency’s guidance for managing major acquisition systems by
establishing, maintaining, and controlling an accurate, valid, and current performance measurement baseline, which would include negotiating all authorized, unpriced work within 3 months; conducting an integrated baseline review of any major contract modifications within 6 months; and preparing a rigorous life-cycle cost estimate, including a risk assessment, in accordance with the Acquisition System Toolset’s guidance and identifying the level of uncertainty inherent in the estimate.
Computer-aided software engineering Computer-Aided Software Engineering (CASE), in the field of Software Engineering is the scientific application of a set of tools and methods to a software which is meant to result in high-quality, defect-free, and maintainable software products. It also refers to methods for the development of information systems together with automated tools that can be used in the software development process.
Overview The term "Computer-aided software engineering" (CASE) can refer to the software used for the automated development of systems software, i.e., computer code. The CASE functions include analysis, design, and programming. CASE tools automate methods for designing, documenting, and producing structured computer code in the desired programming language. Two key ideas of Computer-aided Software System Engineering (CASE) are:
the harboring of computer assistance in software development and or software maintenance processes, and An engineering approach to the software development and or maintenance.
Some typical CASE tools are:
Configuration management tools Data modeling tools Model transformation tools Program transformation tools Refactoring tools Source code generation tools, and Unified Modeling Language
Many CASE tools not only output code but also generate other output typical of various systems analysis and design methodologies such as
data flow diagram entity relationship diagram logical schema Program specification SSADM. User documentation
History of CASE The term CASE was originally coined by software company, Nastec Corporation of Southfield, Michigan in 1982 with their original integrated graphics and text editor GraphiText, which also was the first microcomputer-based system to use hyperlinks to cross-reference text strings in documents — an early forerunner of today's web page link. GraphiText's successor product, DesignAid was the first microprocessor-based tool to logically and semantically evaluate software and system design diagrams and build a data dictionary. Under the direction of Albert F. Case, Jr. vice president for product management and consulting, and Vaughn Frick, director of product management, the DesignAid product suite was expanded to support analysis of a wide range of structured analysis and design methodologies, notable Ed Yourdon and Tom DeMarco, Chris Gane & Trish Sarson, Ward-Mellor (real-time) SA/SD and Warnier-Orr (data driven). The next entrant into the market was Excelerator from Index Technology in Cambridge, Mass. While DesignAid ran on Convergent Technologies and later Burroughs Ngen networked microcomputers, Index launched Excelerator on the IBM PC/AT platform. While, at the time of launch, and for several years, the IBM platform did not support networking or a centralized database as did the Convergent Technologies or Burroughs machines, the allure of IBM was strong, and Excelerator came to prominence. Hot on the
heels of Excelerator were a rash of offerings from companies such as Knowledgeware (James Martin, Fran Tarkenton and Don Addington), Texas Instrument's IEF and Accenture's FOUNDATION toolset (METHOD/1, DESIGN/1, INSTALL/1, FCP). CASE tools were at their peak in the early 1990s. At the time IBM had proposed AD/Cycle which was an alliance of software vendors centered around IBM's Software repository using IBM DB2 in mainframe and OS/2: The application development tools can be from several sources: from IBM, from vendors, and from the customers themselves. IBM has entered into relationships with Bachman Information Systems, Index Technology Corporation, and Knowledgeware, Inc. wherein selected products from these vendors will be marketed through an IBM complementary marketing program to provide offerings that will help to achieve complete life-cycle coverage. With the decline of the mainframe, AD/Cycle and the Big CASE tools died off, opening the market for the mainstream CASE tools of today. Interestingly, nearly all of the leaders of the CASE market of the early 1990s ended up being purchased by Computer Associates, including IEW, IEF, ADW, Cayenne, and Learmonth & Burchett Management Systems (LBMS).
CASE Topics Alfonso Fuggetta classified CASE into 3 categories: 1. Tools support only specific tasks in the software process. 2. Workbenches support only one or a few activities. 3. Environments support (a large part of) the software process. Workbenches and environments are generally built as collections of tools. Tools can therefore be either stand alone products or components of workbenches and environments.
CASE tools CASE tools are a class of software that automates many of the activities involved in various life cycle phases. For example, when establishing the functional requirements of a proposed application, prototyping tools can be used to develop graphic models of application screens to assist end users to visualize how an application will look after development. Subsequently, system designers can use automated design tools to transform the prototyped functional requirements into detailed design documents. Programmers can then use automated code generators to convert the design documents into code. Automated tools can be used collectively, as mentioned, or individually. For example, prototyping tools could be used to define application requirements that get passed to design technicians who convert the requirements into detailed designs in a
traditional manner using flowcharts and narrative documents, without the assistance of automated design software. Existing CASE Environments can be classified along 4 different dimensions : 1. 2. 3. 4.
Life-Cycle Support Integration Dimension Construction Dimension Knowledge Based CASE dimension
Let us take the meaning of these dimensions along with their examples one by one : Life-Cycle Based CASE Tools This dimension classifies CASE Tools on the basis of the activities they support in the information systems life cycle. They can be classified as Upper or Lower CASE tools.
Upper CASE Tools: support strategic, planning and construction of conceptual level product and ignore the design aspect. They support traditional diagrammatic languages such as ER diagrams, Data flow diagram, Structure charts etc. Lower CASE Tools: concentrate on the back end activities of the software life cycle and hence support activities like physical design, debugging, construction, testing, integration of software components, maintenance, reengineering and reverse engineering activities.
Integration Dimension Three main CASE Integration dimension have been proposed : 1. CASE Framework 2. ICASE Tools 3. Integrated Project Support Environment(IPSE)
CASE Workbenches Workbenches integrate several CASE tools into one application to support specific software-process activities. Hence they achieve:
a homogeneous and consistent interface (presentation integration). easy invocation of tools and tool chains (control integration). access to a common data set managed in a centralized way (data integration).
CASE workbenches can be further classified into following 8 classes: 1. Business planning and modeling 2. Analysis and design
3. 4. 5. 6. 7. 8.
User-interface development Programming Verification and validation Maintenance and reverse engineering Configuration management Project management
CASE Environments An environment is a collection of CASE tools and workbenches that supports the software process. CASE environments are classified based on the focus/basis of integration 1. 2. 3. 4. 5.
Toolkits Language-centered Integrated Fourth generation Process-centered
Toolkits Toolkits are loosely integrated collections of products easily extended by aggregating different tools and workbenches. Typically, the support provided by a toolkit is limited to programming, configuration management and project management. And the toolkit itself is environments extended from basic sets of operating system tools, for example, the Unix Programmer's Work Bench and the VMS VAX Set. In addition, toolkits' loose integration requires user to activate tools by explicit invocation or simple control mechanisms. The resulting files are unstructured and could be in different format, therefore the access of file from different tools may require explicit file format conversion. However, since the only constraint for adding a new component is the formats of the files, toolkits can be easily and incrementally extended. Language-centered The environment itself is written in the programming language for which it was developed, thus enable users to reuse, customize and extend the environment. Integration of code in different languages is a major issue for language-centered environments. Lack of process and data integration is also a problem. The strengths of these environments include good level of presentation and control integration. Interlisp, Smalltalk, Rational, and KEE are examples of language-centered environments. Integrated These environment achieve presentation integration by providing uniform, consistent, and coherent tool and workbench interfaces. Data integration is achieved through the repository concept: they have a specialized database managing all information produced
and accessed in the environment. Examples of integrated environment are IBM AD/Cycle and DEC Cohesion. Fourth generation Forth generation environments were the first integrated environments. They are sets of tools and workbenches supporting the development of a specific class of program: electronic data processing and business-oriented applications. In general, they include programming tools, simple configuration management tools, document handling facilities and, sometimes, a code generator to produce code in lower level languages. Informix 4GL, and Focus fall into this category. Process-centered Environments in this category focus on process integration with other integration dimensions as starting points. A process-centered environment operates by interpreting a process model created by specialized tools. They usually consist of tools handling two functions:
Process-model execution, and Process-model production
Examples are East, Enterprise II, Process Wise, Process Weaver, and Arcadia.
Applications All aspects of the software development life cycle can be supported by software tools, and so the use of tools from across the spectrum can, arguably, be described as CASE; from project management software through tools for business and functional analysis, system design, code storage, compilers, translation tools, test software, and so on. However, it is the tools that are concerned with analysis and design, and with using design information to create parts (or all) of the software product, that are most frequently thought of as CASE tools. CASE applied, for instance, to a database software product, might normally involve:
Modelling business / real world processes and data flow Development of data models in the form of entity-relationship diagrams Development of process and function descriptions Production of database creation SQL and stored procedures
Risks and associated controls Common CASE risks and associated controls include:
Inadequate Standardization : Linking CASE tools from different vendors (design tool from Company X, programming tool from Company Y) may be difficult if the products do not use standardized code structures and data classifications. File formats can be converted, but usually not economically. Controls include using tools from the same vendor, or using tools based on standard protocols and insisting on demonstrated compatibility. Additionally, if organizations obtain tools for only a portion of the development process, they should consider acquiring them from a vendor that has a full line of products to ensure future compatibility if they add more tools.
Unrealistic Expectations : Organizations often implement CASE technologies to reduce development costs. Implementing CASE strategies usually involves high start-up costs. Generally, management must be willing to accept a long-term payback period. Controls include requiring senior managers to define their purpose and strategies for implementing CASE technologies.
Quick Implementation : Implementing CASE technologies can involve a significant change from traditional development environments. Typically, organizations should not use CASE tools the first time on critical projects or projects with short deadlines because of the lengthy training process. Additionally, organizations should consider using the tools on smaller, less complex projects and gradually implementing the tools to allow more training time.
Weak Repository Controls : Failure to adequately control access to CASE repositories may result in security breaches or damage to the work documents, system designs, or code modules stored in the repository. Controls include protecting the repositories with appropriate access, version, and backup controls.
Software quality In the context of software engineering, software quality measures how well software is designed (quality of design), and how well the software conforms to that design (quality of conformance), although there are several different definitions. Whereas quality of conformance is concerned with implementation (see Software Quality Assurance), quality of design measures how valid the design and requirements are in creating a worthwhile product.
Definition One of the challenges of Software Quality is that "everyone feels they understand it". A definition in Steve McConnell's Code Complete divides software into two pieces: internal and external quality characteristics. External quality characteristics are those
parts of a product that face its users, where internal quality characteristics are those that do not. Another definition by Dr. Tom DeMarco says "a product's quality is a function of how much it changes the world for the better." This can be interpreted as meaning that user satisfaction is more important than anything in determining software quality. Another definition, coined by Gerald Weinberg in Quality Software Management: Systems Thinking, is "Quality is value to some person." This definition stresses that quality is inherently subjective - different people will experience the quality of the same software very differently. One strength of this definition is the questions it invites software teams to consider, such as "Who are the people we want to value our software?" and "What will be valuable to them?"
History Software product quality
Product quality o conformance to requirements or program specification; related to Reliability Scalability Correctness Completeness Absence of bugs Fault-tolerance o Extensibility o Maintainability Documentation
Source code quality A computer has no concept of "well-written" source code. However, from a human point of view source code can be written in a way that has an effect on the effort needed to comprehend its behavior. Many source code programming style guides, which often stress readability and usually language-specific conventions are aimed at reducing the cost of source code maintenance. Some of the issues that affect code quality include:
Readability Ease of maintenance, testing, debugging, fixing, modification and portability Low complexity Low resource consumption: memory, CPU Number of compilation or lint warnings Robust input validation and error handling, established by software fault injection
Methods to improve the quality:
Refactoring Code Inspection or software review Documenting code
Software reliability Software reliability is an important facet of software quality. It is defined as "the probability of failure-free operation of a computer program in a specified environment for a specified time". One of reliability's distinguishing characteristics is that it is objective, measurable, and can be estimated, whereas much of software quality is subjective criteria. This distinction is especially important in the discipline of Software Quality Assurance. These measured criteria are typically called software metrics.
History With software embedded into many devices today, software failure has caused more than inconvenience. Software errors have even caused human fatalities. The causes have ranged from poorly designed user interfaces to direct programming errors. An example of a programming error that lead to multiple deaths is discussed in Dr. Leveson's paper (PDF). This has resulted in requirements for development of some types software. In the United States, both the Food and Drug Administration (FDA) and Federal Aviation Administration (FAA) have requirements for software development.
The goal of reliability The need for a means to objectively determine software quality comes from the desire to apply the techniques of contemporary engineering fields to the development of software. That desire is a result of the common observation, by both lay-persons and specialists, that computer software does not work the way it ought to. In other words, software is seen to exhibit undesirable behaviour, up to and including outright failure, with consequences for the data which is processed, the machinery on which the software runs, and by extension the people and materials which those machines might negatively affect. The more critical the application of the software to economic and production processes, or to life-sustaining systems, the more important is the need to assess the software's reliability. Regardless of the criticality of any single software application, it is also more and more frequently observed that software has penetrated deeply into most every aspect of modern life through the technology we use. It is only expected that this infiltration will continue, along with an accompanying dependency on the software by the systems which maintain our society. As software becomes more and more crucial to the operation of the systems on which we depend, the argument goes, it only follows that the software should offer a concomitant level of dependability. In other words, the software should behave in the way it is intended, or even better, in the way it should.
The challenge of reliability The circular logic of the preceding sentence is not accidental—it is meant to illustrate a fundamental problem in the issue of measuring software reliability, which is the difficulty of determining, in advance, exactly how the software is intended to operate. The problem seems to stem from a common conceptual error in the consideration of software, which is that software in some sense takes on a role which would otherwise be filled by a human being. This is a problem on two levels. Firstly, most modern software performs work which a human could never perform, especially at the high level of reliability that is often expected from software in comparison to humans. Secondly, software is fundamentally incapable of most of the mental capabilities of humans which separate them from mere mechanisms: qualities such as adaptability, general-purpose knowledge, a sense of conceptual and functional context, and common sense. Nevertheless, most software programs could safely be considered to have a particular, even singular purpose. If the possibility can be allowed that said purpose can be well or even completely defined, it should present a means for at least considering objectively whether the software is, in fact, reliable, by comparing the expected outcome to the actual outcome of running the software in a given environment, with given data. Unfortunately, it is still not known whether it is possible to exhaustively determine either the expected outcome or the actual outcome of the entire set of possible environment and input data to a given program, without which it is probably impossible to determine the program's reliability with any certainty. However, various attempts are in the works to attempt to rein in the vastness of the space of software's environmental and input variables, both for actual programs and theoretical descriptions of programs. Such attempts to improve software reliability can be applied at different stages of a program's development, in the case of real software. These stages principally include: requirements, design, programming, testing, and runtime evaluation. The study of theoretical software reliability is predominantly concerned with the concept of correctness, a mathematical field of computer science which is an outgrowth of language and automata theory.
Reliability in program development
Requirements A program cannot be expected to work as desired if the developers of the program do not, in fact, know the program's desired behaviour in advance, or if they cannot at least determine its desired behaviour in parallel with development, in sufficient detail. What level of detail is considered sufficient is hotly debated. The idea of perfect detail is attractive, but may be impractical, if not actually impossible, in practice. This is because the desired behaviour tends to change as the possible range of the behaviour is determined through actual attempts, or more accurately, failed attempts, to achieve it.
Whether a program's desired behaviour can be successfully specified in advance is a moot point if the behaviour cannot be specified at all, and this is the focus of attempts to formalize the process of creating requirements for new software projects. In situ with the formalization effort is an attempt to help inform non-specialists, particularly nonprogrammers, who commission software projects without sufficient knowledge of what computer software is in fact capable. Communicating this knowledge is made more difficult by the fact that, as hinted above, even programmers cannot always know in advance what is actually possible for software in advance of trying.
Design While requirements are meant to specify what a program should do, design is meant, at least at a high level, to specify how the program should do it. The usefulness of design is also questioned by some, but those who look to formalize the process of ensuring reliability often offer good software design processes as the most significant means to accomplish it. Software design usually involves the use of more abstract and general means of specifying the parts of the software and what they do. As such, it can be seen as a way to break a large program down into many smaller programs, such that those smaller pieces together do the work of the whole program. The purposes of high-level design are as follows. It separates what are considered to be problems of architecture, or overall program concept and structure, from problems of actual coding, which solve problems of actual data processing. It applies additional constraints to the development process by narrowing the scope of the smaller software components, and thereby—it is hoped—removing variables which could increase the likelihood of programming errors. It provides a program template, including the specification of interfaces, which can be shared by different teams of developers working on disparate parts, such that they can know in advance how each of their contributions will interface with those of the other teams. Finally, and perhaps most controversially, it specifies the program independently of the implementation language or languages, thereby removing language-specific biases and limitations which would otherwise creep into the design, perhaps unwittingly on the part of programmer-designers.
Programming The history of computer programming language development can often be best understood in the light of attempts to master the complexity of computer programs, which otherwise becomes more difficult to understand in proportion (perhaps exponentially) to the size of the programs. (Another way of looking at the evolution of programming languages is simply as a way of getting the computer to do more and more of the work, but this may be a different way of saying the same thing.) Lack of understanding of a program's overall structure and functionality is a sure way to fail to detect errors in the program, and thus the use of better languages should, conversely, reduce the number of errors by enabling a better understanding.
Improvements in languages tend to provide incrementally what software design has attempted to do in one fell swoop: consider the software at ever greater levels of abstraction. Such inventions as statement, sub-routine, file, class, template, library, component and more have allowed the arrangement of a program's parts to be specified using abstractions such as layers, hierarchies and modules, which provide structure at different granularities, so that from any point of view the program's code can be imagined to be orderly and comprehensible. In addition, improvements in languages have enabled more exact control over the shape and use of data elements, culminating in the abstract data type. These data types can be specified to a very fine degree, including how and when they are accessed, and even the state of the data before and after it is accessed.
Software Build and Deployment Many programming languages such as C and Java require the program "source code" to be translated in to a form that can be executed by a computer. This translation is done by a program called a compiler. Additional operations may be involved to associate, bind, link or package files together in order to create a usable runtime configuration of the software application. The totality of the compiling and assembly process is generically called "building" the software. The software build is critical to software quality because if any of the generated files are incorrect the software build is likely to fail. And, if the incorrect version of a program is inadvertently used, then testing can lead to false results. Software builds are typically done in work area unrelated to the runtime area, such as the application server. For this reason, a deployment step is needed to physically transfer the software build products to the runtime area. The deployment procedure may also involve technical parameters, which, if set incorrectly, can also prevent software testing from beginning. For example, a Java application server may have options for parent-first or parent-last class loading. Using the incorrect parameter can cause the application to fail to execute on the application server. The technical activities supporting software quality including build, deployment, change control and reporting are collectively known as Software configuration management. A number of software tools have arisen to help meet the challenges of configuration management including file control tools and build control tools.
Testing Software Testing Software testing, when done correctly, can increase overall software quality of conformance by testing that the product conforms to its requirements. Testing includes, but is not limited to:
1. 2. 3. 4. 5. 6.
Unit Testing Functional Testing Regression Testing Performance Testing Failover Testing Usability Testing
A number of agile methodologies use testing early in the development cycle to ensure quality in their products. For example, the test-driven development practice, where tests are written before the code they will test, is used in Extreme Programming to ensure quality.
Runtime runtime reliability determinations are similar to tests, but go beyond simple confirmation of behaviour to the evaluation of qualities such as performance and interoperability with other code or particular hardware configurations.
Software Quality Factors A software quality factor is a non-functional requirement for a software program which is not called up by the customer's contract, but nevertheless is a desirable requirement which enhances the quality of the software program. Note that none of these factors are binary; that is, they are not “either you have it or you don’t” traits. Rather, they are characteristics that one seeks to maximize in one’s software to optimize its quality. So rather than asking whether a software product “has” factor x, ask instead the degree to which it does (or does not). Some software quality factors are listed here: Understandability–clarity of purpose. This goes further than just a statement of purpose; all of the design and user documentation must be clearly written so that it is easily understandable. This is obviously subjective in that the user context must be taken into account: for instance, if the software product is to be used by software engineers it is not required to be understandable to the layman. Completeness–presence of all constituent parts, with each part fully developed. This means that if the code calls a subroutine from an external library, the software package must provide reference to that library and all required parameters must be passed. All required input data must also be available. Conciseness–minimization of excessive or redundant information or processing. This is important where memory capacity is limited, and it is generally considered good practice to keep lines of code to a minimum. It can be improved by replacing repeated functionality by one subroutine or function which achieves that functionality. It also applies to documents.
Portability–ability to be run well and easily on multiple computer configurations. Portability can mean both between different hardware—such as running on a PC as well as a smartphone—and between different operating systems—such as running on both Mac OS X and GNU/Linux. Consistency–uniformity in notation, symbology, appearance, and terminology within itself. Maintainability–propensity to facilitate updates to satisfy new requirements. Thus the software product that is maintainable should be well-documented, should not be complex, and should have spare capacity for memory, storage and processor utilization and other resources. Testability–disposition to support acceptance criteria and evaluation of performance. Such a characteristic must be built-in during the design phase if the product is to be easily testable; a complex design leads to poor testability. Usability–convenience and practicality of use. This is affected by such things as the human-computer interface. The component of the software that has most impact on this is the user interface (UI), which for best usability is usually graphical (i.e. a GUI). Reliability–ability to be expected to perform its intended functions satisfactorily. This implies a time factor in that a reliable product is expected to perform correctly over a period of time. It also encompasses environmental considerations in that the product is required to perform correctly in whatever conditions it finds itself (sometimes termed robustness). Structuredness–organisation of constituent parts in a definite pattern. A software product written in a block-structured language such as Pascal will satisfy this characteristic. Efficiency–fulfillment of purpose without waste of resources, such as memory, space and processor utilization, network bandwidth, time, etc. Security–ability to protect data against unauthorized access and to withstand malicious or inadvertent interference with its operations. Besides the presence of appropriate security mechanisms such as authentication, access control and encryption, security also implies resilience in the face of malicious, intelligent and adaptive attackers.
Measurement of software quality factors There are varied perspectives within the field on measurement. There are a great many measures that are valued by some professionals—or in some contexts, that are decried as harmful by others. Some believe that quantitative measures of software quality are essential. Others believe that contexts where quantitative measures are useful are quite rare, and so prefer qualitative measures. Several leaders in the field of software testing
have written about the difficulty of measuring what we truly want to measure well, including Dr. Cem Kaner (PDF) and Douglass Hoffman (PDF). One example of a popular metric is the number of faults encountered in the software. Software that contains few faults is considered by some to have higher quality than software that contains many faults. Questions that can help determine the usefulness of this metric in a particular context include: 1. What constitutes “many faults?” Does this differ depending upon the purpose of the software (e.g., blogging software vs. navigational software)? Does this take into account the size and complexity of the software? 2. Does this account for the importance of the bugs (and the importance to the stakeholders of the people those bugs bug)? Does one try to weight this metric by the severity of the fault, or the incidence of users it affects? If so, how? And if not, how does one know that 100 faults discovered is better than 1000? 3. If the count of faults being discovered is shrinking, how do I know what that means? For example, does that mean that the product is now higher quality than it was before? Or that this is a smaller/less ambitious change than before? Or that fewer tester-hours have gone into the project than before? Or that this project was tested by less skilled testers than before? Or that the team has discovered that fewer faults reported is in their interest? This last question points to an especially difficult one to manage. All software quality metrics are in some sense measures of human behavior, since humans create software(PDF). If a team discovers that they will benefit from a drop in the number of reported bugs, there is a strong tendency for the team to start reporting fewer defects. That may mean that email begins to circumvent the bug tracking system, or that four or five bugs get lumped into one bug report, or that testers learn not to report minor annoyances. The difficulty is measuring what we mean to measure, without creating incentives for software programmers and testers to consciously or unconsciously “game” the measurements. Software quality factors cannot be measured because of their vague definitions. It is necessary to find measurements, or metrics, which can be used to quantify them as nonfunctional requirements. For example, reliability is a software quality factor, but cannot be evaluated in its own right. However, there are related attributes to reliability, which can indeed be measured. Some such attributes are mean time to failure, rate of failure occurrence, and availability of the system. Similarly, an attribute of portability is the number of target-dependent statements in a program. A scheme that could be used for evaluating software quality factors is given below. For every characteristic, there are a set of questions which are relevant to that characteristic. Some type of scoring formula could be developed based on the answers to these questions, from which a measurement of the characteristic can be obtained.
Understandability Are variable names descriptive of the physical or functional property represented? Do uniquely recognisable functions contain adequate comments so that their purpose is clear? Are deviations from forward logical flow adequately commented? Are all elements of an array functionally related?..
Completeness Are all necessary components available? Does any process fail for lack of resources or programming? Are all potential pathways through the code accounted for, including proper error handling?
Conciseness Is all code reachable? Is any code redundant? How many statements within loops could be placed outside the loop, thus reducing computation time? Are branch decisions too complex?
Portability Does the program depend upon system or library routines unique to a particular installation? Have machine-dependent statements been flagged and commented? Has dependency on internal bit representation of alphanumeric or special characters been avoided? How much effort would be required to transfer the program from one hardware/software system or environment to another?
Consistency Is one variable name used to represent different logical or physical entities in the program? Does the program contain only one representation for any given physical or mathematical constant? Are functionally similar arithmetic expressions similarly constructed? Is a consistent scheme used for indentation, nomenclature, the color palette, fonts and other visual elements?
Maintainability Has some memory capacity been reserved for future expansion? Is the design cohesive— i.e., does each module have distinct, recognisable functionality? Does the software allow for a change in data structures (object-oriented designs are more likely to allow for this)? If the code is procedure-based (rather than object-oriented), is a change likely to require restructuring the main program, or just a module?
Testability Are complex structures employed in the code? Does the detailed design contain clear pseudo-code? Is the pseudo-code at a higher level of abstraction than the code? If tasking is used in concurrent designs, are schemes available for providing adequate test cases?
Usability Is a GUI used? Is there adequate on-line help? Is a user manual provided? Are meaningful error messages provided?
Reliability Are loop indexes range-tested? Is input data checked for range errors? Is divide-by-zero avoided? Is exception handling provided?
Structuredness Is a block-structured programming language used? Are modules limited in size? Have the rules for transfer of control between modules been established and followed?
Efficiency Have functions been optimized for speed? Have repeatedly used blocks of code been formed into subroutines? Has the program been checked for memory leaks or overflow errors?
Security Does the software protect itself and its data against unauthorized access and use? Does it allow its operator to enforce security policies? Are security mechanisms appropriate, adequate and correctly implemented? Can the software withstand attacks that can be anticipated in its intended environment? Is the software free of errors that would make it possible to circumvent its security mechanisms? Does the architecture limit the potential impact of yet unknown errors?
Software maintenance Software maintenance in software engineering is the modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment (ISO/IEC 14764).
Overview This international standard describes the 6 software maintenance processes as: 1. The implementation processes contains software preparation and transition activities, such as the conception and creation of the maintenance plan, the preparation for handling problems identified during development, and the followup on product configuration management. 2. The problem and modification analysis process, which is executed once the application has become the responsibility of the maintenance group. The maintenance programmer must analyze each request, confirm it (by reproducing the situation) and check its validity, investigate it and propose a solution, document the request and the solution proposal, and, finally, obtain all the required authorizations to apply the modifications. 3. The process considering the implementation of the modification itself. 4. The process acceptance of the modification, by checking it with the individual who submitted the request in order to make sure the modification provided a solution. 5. The migration process (platform migration, for example) is exceptional, and is not part of daily maintenance tasks. If the software must be ported to another platform without any change in functionality, this process will be used and a maintenance project team is likely to be assigned to this task. 6. Finally, the last maintenance process, also an event which does not occur on a daily basis, is the retirement of a piece of software. There are a number of processes, activities and practices that are unique to maintainers, for example:
Transition: a controlled and coordinated sequence of activities during which a system is transferred progressively from the developer to the maintainer; Service Level Agreements (SLAs) and specialized (domain-specific) maintenance contracts negotiated by maintainers; Modification Request and Problem Report Help Desk: a problem-handling process used by maintainers to prioritize, documents and route the requests they receive; Modification Request acceptance/rejection: modification request work over a certain size/effort/complexity may be rejected by maintainers and rerouted to a developer.
A common perception of maintenance is that it is merely fixing bugs. However, studies and surveys over the years have indicated that the majority, over 80%, of the maintenance effort is used for non-corrective actions (Pigosky 1997). This perception is perpetuated by users submitting problem reports that in reality are functionality enhancements to the system.
Software maintenance and evolution of systems was first addressed by Meir M. Lehman in 1969. Over a period of twenty years, his research led to the formulation of eight Laws of Evolution (Lehman 1997). Key findings of his research include that maintenance is really evolutionary developments and that maintenance decisions are aided by understanding what happens to systems (and software) over time. Lehman demonstrated that systems continue to evolve over time. As they evolve, they grow more complex unless some action such as code refactoring is taken to reduce the complexity. The key software maintenance issues are both managerial and technical. Key management issues are: alignment with customer priorities, staffing, which organization does maintenance, estimating costs. Key technical issues are: limited understanding, impact analysis, testing, maintainability measurement.
Categories of maintenance in ISO/IEC 14764 E.B. Swanson initially identified three categories of maintenance: corrective, adaptive, and perfective. These have since been updated and ISO/IEC 14764 presents:
Corrective maintenance: Reactive modification of a software product performed after delivery to correct discovered problems. Adaptive maintenance: Modification of a software product performed after delivery to keep a software product usable in a changed or changing environment. Perfective maintenance: Modification of a software product after delivery to improve performance or maintainability. Preventive maintenance: Modification of a software product after delivery to detect and correct latent faults in the software product before they become effective faults.
Software configuration management In software engineering, software configuration management (SCM) is the task of tracking and controlling changes in the software. Configuration management practices include revision control and the establishment of baselines. SCM concerns itself with answering the question "Somebody did something, how can one reproduce it?" Often the problem involves not reproducing "it" identically, but with controlled, incremental changes. Answering the question thus becomes a matter of comparing different results and of analysing their differences. Traditional configuration management typically focused on controlled creation of relatively simple products. Now, implementers of SCM face the challenge of dealing with relatively minor increments under their own control, in the context of the complex system being developed.
Terminology
The history and terminology of SCM (which often varies) has given rise to controversy. Roger Pressman, in his book Software Engineering: A Practitioner's Approach, states that SCM is a "set of activities designed to control change by identifying the work products that are likely to change, establishing relationships among them, defining mechanisms for managing different versions of these work products, controlling the changes imposed, and auditing and reporting on the changes made." Source configuration management is a related practice often used to indicate that a variety of artifacts may be managed and versioned, including software code, documents, design models, and even the directory structure itself. Atria (later Rational Software, now a part of IBM), used "SCM" to mean "software configuration management". Gartner uses the term software change and configuration management.
Purposes The goals of SCM are generally:
Configuration identification - Identifying configurations, configuration items and baselines. Configuration control - Implementing a controlled change process. This is usually achieved by setting up a change control board whose primary function is to approve or reject all change requests that are sent against any baseline. Configuration status accounting - Recording and reporting all the necessary information on the status of the development process. Configuration auditing - Ensuring that configurations contain all their intended parts and are sound with respect to their specifying documents, including requirements, architectural specifications and user manuals. Build management - Managing the process and tools used for builds. Process management - Ensuring adherence to the organization's development process. Environment management - Managing the software and hardware that host our system. Teamwork - Facilitate team interactions related to the process. Defect tracking - Making sure every defect has traceability back to the source.
