Software Engineering Body of Knowledge (v3) (2014) (811503), страница 63
Текст из файла (страница 63)
It refers to both theprocess and result of generalization by reducingthe information of a concept, a problem, or anobservable phenomenon so that one can focuson the “big picture.” One of the most importantskills in any engineering undertaking is framingthe levels of abstraction appropriately.“Through abstraction,” according to Voland,“we view the problem and its possible solutionpaths from a higher level of conceptual understanding. As a result, we may become better prepared to recognize possible relationships betweendifferent aspects of the problem and thereby generate more creative design solutions” [2*].
Thisis particularly true in computer science in general(such as hardware vs. software) and in softwareengineering in particular (data structure vs. dataflow, and so forth).2.1. Levels of AbstractionWhen abstracting, we concentrate on one “level”of the big picture at a time with confidence thatwe can then connect effectively with levels aboveand below.
Although we focus on one level,abstraction does not mean knowing nothing aboutthe neighboring levels. Abstraction levels do notnecessarily correspond to discrete componentsin reality or in the problem domain, but to welldefined standard interfaces such as programmingAPIs. The advantages that standard interfacesprovide include portability, easier software/hardware integration and wider usage.2.2. EncapsulationEncapsulation is a mechanism used to implement abstraction. When we are dealing with onelevel of abstraction, the information concerningthe levels below and above that level is encapsulated.
This information can be the concept, problem, or observable phenomenon; or it may be thepermissible operations on these relevant entities.Encapsulation usually comes with some degreeof information hiding in which some or all ofthe underlying details are hidden from the levelabove the interface provided by the abstraction.To an object, information hiding means we don’tneed to know the details of how the object is represented or how the operations on those objectsare implemented.2.3. HierarchyWhen we use abstraction in our problem formulation and solution, we may use different abstractionsComputing Foundations 13-5at different times—in other words, we work on different levels of abstraction as the situation calls.Most of the time, these different levels of abstraction are organized in a hierarchy. There are manyways to structure a particular hierarchy and thecriteria used in determining the specific content ofeach layer in the hierarchy varies depending on theindividuals performing the work.Sometimes, a hierarchy of abstraction is sequential, which means that each layer has one and onlyone predecessor (lower) layer and one and onlyone successor (upper) layer—except the upmostlayer (which has no successor) and the bottommostlayer (which has no predecessor).
Sometimes,however, the hierarchy is organized in a tree-likestructure, which means each layer can have morethan one predecessor layer but only one successorlayer. Occasionally, a hierarchy can have a manyto-many structure, in which each layer can havemultiple predecessors and successors. At no time,shall there be any loop in a hierarchy.A hierarchy often forms naturally in task decomposition. Often, a task analysis can be decomposedin a hierarchical fashion, starting with the largertasks and goals of the organization and breakingeach of them down into smaller subtasks that canagain be further subdivided This continuous division of tasks into smaller ones would produce ahierarchical structure of tasks-subtasks.2.4. Alternate AbstractionsSometimes it is useful to have multiple alternateabstractions for the same problem so that one cankeep different perspectives in mind.
For example, we can have a class diagram, a state chart,and a sequence diagram for the same softwareat the same level of abstraction. These alternateabstractions do not form a hierarchy but rathercomplement each other in helping understandingthe problem and its solution. Though beneficial, itis as times difficult to keep alternate abstractionsin sync.3. Programming Fundamentals[3*, c6–19]Programming is composed of the methodologiesor activities for creating computer programs thatperform a desired function. It is an indispensiblepart in software construction.
In general, programming can be considered as the process ofdesigning, writing, testing, debugging, and maintaining the source code. This source code is written in a programming language.The process of writing source code oftenrequires expertise in many different subjectareas—including knowledge of the applicationdomain, appropriate data structures, specialized algorithms, various language constructs,good programming techniques, and softwareengineering.3.1. The Programming ProcessProgramming involves design, writing, testing,debugging, and maintenance. Design is the conception or invention of a scheme for turning acustomer requirement for computer software intooperational software.
It is the activity that linksapplication requirements to coding and debugging. Writing is the actual coding of the designin an appropriate programming language. Testingis the activity to verify that the code one writesactually does what it is supposed to do. Debugging is the activity to find and fix bugs (faults) inthe source code (or design). Maintenance is theactivity to update, correct, and enhance existingprograms. Each of these activities is a huge topicand often warrants the explanation of an entireKA in the SWEBOK Guide and many books.3.2. Programming ParadigmsProgramming is highly creative and thus somewhat personal.
Different people often write different programs for the same requirements. Thisdiversity of programming causes much difficultyin the construction and maintenance of largecomplex software. Various programming paradigms have been developed over the years to putsome standardization into this highly creative andpersonal activity. When one programs, he or shecan use one of several programming paradigms towrite the code. The major types of programmingparadigms are discussed below.Unstructured Programming: In unstructuredprogramming, a programmer follows his/her13-6 SWEBOK® Guide V3.0hunch to write the code in whatever way he/shelikes as long as the function is operational.
Often,the practice is to write code to fulfill a specificutility without regard to anything else. Programswritten this way exhibit no particular structure—thus the name “unstructured programming.”Unstructured programming is also sometimescalled ad hoc programming.Structured/Procedural/ Imperative Programming: A hallmark of structured programming isthe use of well-defined control structures, including procedures (and/or functions) with each procedure (or function) performing a specific task.Interfaces exist between procedures to facilitatecorrect and smooth calling operations of the programs. Under structured programming, programmers often follow established protocols and rulesof thumb when writing code.
These protocolsand rules can be numerous and cover almost theentire scope of programming—ranging from thesimplest issue (such as how to name variables,functions, procedures, and so forth) to more complex issues (such as how to structure an interface,how to handle exceptions, and so forth).Object-Oriented Programming: While procedural programming organizes programs aroundprocedures, object-oriented programming (OOP)organize a program around objects, which areabstract data structures that combine both dataand methods used to access or manipulate thedata.
The primary features of OOP are that objectsrepresenting various abstract and concrete entitiesare created and these objects interact with eachother to collectively fulfill the desired functions.Aspect-Oriented Programming: Aspect-oriented programming (AOP) is a programmingparadigm that is built on top of OOP.
AOP aimsto isolate secondary or supporting functions fromthe main program’s business logic by focusingon the cross sections (concerns) of the objects.The primary motivation for AOP is to resolvethe object tangling and scattering associated withOOP, in which the interactions among objectsbecome very complex.
The essence of AOP isthe greatly emphasized separation of concerns,which separates noncore functional concerns orlogic into various aspects.Functional Programming: Though less popular, functional programming is as viable asthe other paradigms in solving programmingproblems. In functional programming, all computations are treated as the evaluation of mathematical functions.
In contrast to the imperativeprogramming that emphasizes changes in state,functional programming emphasizes the application of functions, avoids state and mutable data,and provides referential transparency.4. Programming Language Basics[4*, c6]Using computers to solve problems involvesprogramming—which is writing and organizing instructions telling the computer what to doat each step. Programs must be written in someprogramming language with which and throughwhich we describe necessary computations. Inother words, we use the facilities provided by aprogramming language to describe problems,develop algorithms, and reason about problemsolutions. To write any program, one must understand at least one programming language.4.1. Programming Language OverviewA programming language is designed to expresscomputations that can be performed by a computer.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
