[ Pobierz całość w formacie PDF ]
.As we studied their system, we encountered large segments of code that baffled us.Thesesegments didn t seem to contribute to the overall architecture that we had expected to find.They were somewhat incohesive and only very sparsely documented, if at all.When weasked the current developers about some of these segments, the reply was, Oh that? Wellwe re not using that approach anymore.Reggie was trying something, but we came up with abetter way.I guess some of Reggie s other code may depend on that stuff though, so wedidn t delete anything. As we looked deeper into the matter, we learned that Reggie was nolonger even at the site, and hadn t been there for some time, so the segments of code wereseveral months old.After two days of code examination, we realized that the majority of the code that comprisedthe system was most likely similar to that code that we already examined: completely LavaFlow in nature.We gleaned very little that helped us articulate how their architecture actuallywas constructed; therefore, it was nearly impossible to mine.At this point, we essentiallygave up trying to mine the code and instead focused on the current developer s explanationsof what was really going on, hoping to somehow codify their work into interface extensionsthat we could incorporate into our upcoming revisions to our generic interapplicationframework.One solution was to isolate the single, key person who best understood the system they haddeveloped, and then to jointly write IDL with that person.On the surface, the purpose of theIDL we were jointly writing was to support a crisis demonstration that was weeks away.Byutilizing the Fire Drill Mini-AntiPattern, we were able to get the systems developers tovalidate our IDL by using it to rapidly build a CORBA wrapper for their product for thedemonstration.Many people lost a lot of sleep, but the demonstration went well.There was,of course, one side effect to this solution: We ended up with the interface, in IDL, which wehad set out to discover in the first place.Related SolutionsIn today s competitive world, it is often desirable to minimize the time delay between R&Dand production.In many industries, this is critical to a company s survival.Where this is thecase, inoculation against Lava Flow can sometimes be found in a customizedconfiguration-management (CM) process that puts certain limiting controls in place at theprototyping stage, similar to hooks into a real, production-class develop ment without thefull restraining impact on the experimental nature of R&D.Where possible, automation canplay a big role here, but the key lies in the customization of a quasi-CM process that can bereadily scaled into a full-blown CM control system once the product moves into a productionenvironment.The issue is one of balance between the costs of CM in hampering the creativeprocess and the cost of rapidly gaining CM control of the development once that creativeprocess has birthed something useful and marketable.This approach can be facilitated by periodic mapping of a prototyping system into an updatedsystem architecture, including limited, but standardized inline documentation of the code.Applicability To Other Viewpoints And ScalesThe architectural viewpoint plays a key role in preventing Lava Flows initially.Managers canalso play a role in early identification of Lava Flows or the circumstances that can lead toLava Flows.These managers must also have the authority to put the brakes on when LavaFlow is first identified, postponing further development until a clear architecture can bedefined and disseminated.As with most AntiPatterns, prevention is always cheaper than correction, so up-frontinvestment in good architecture and team education can typically ensure a project againstthis and most other AntiPatterns.While this initial cost does not show immediate returns, it is53 certainly a good investment.Mini-AntiPattern: Ambiguous ViewpointAntiPattern ProblemObject-oriented analysis and design (OOA&D) models are often presented withoutclarifying the viewpoint represented by the model.By default, OOA&D models denotean implementation viewpoint that is potentially the least useful.Mixed viewpoints don tallow the fundamental separation of interfaces from implementation details, which areone of the primary benefits of the object-oriented paradigm.Refactored SolutionThere are three fundamental viewpoints for OOA&D models: the business viewpoint,the specification viewpoint, and the implementation viewpoint.The business viewpointdefines the user s model of the information and processes.This is a model that domainexperts can defend and explain (commonly called an analysis model).Analysis modelsare some of the most stable models of the information system and are worthwhile tomaintain.Models can be less useful if they don t focus on the required perspective(s).Aperspective applies filters to the information.For example, defining a class model for atelephone exchange system will vary significantly depending upon the focus providedby the following perspectives:" Telephone user, who cares about the ease of making calls and receiving itemizedbills." Telephone operator, who cares about connecting users to required numbers." Telephone accounting department, which cares about the formulae for billing andrecords of all calls made by users.Some of the same classes will be identified, but not many; where there are, themethods will not be the same.The specification viewpoint focuses on software interfaces.Because objects (asabstract data types) are intended to hide implementation details behind interfaces, thespecification viewpoint defines the exposed abstractions and behaviors in the objectsystem.The specification viewpoint defines the software boundaries between objectsin the system.The implementation viewpoint defines the internal details of the objects.Implementation models are often called design models in practice.To be an accuratemodel of the software, design models must be maintained continuously as the softwareis developed and modified.Since an out-of-date model is useless, only selecteddesign models are pertinent to maintain; in particular, those design models that depictcomplex aspects of the system.Functional DecompositionAntiPattern Name: Functional DecompositionAlso Known As: No Object-Oriented AntiPattern No OO [Akroyd 96]Most Frequent Scale: ApplicationRefactored Solution Name: Object-Oriented ReengineeringRefactored Solution Type: ProcessRoot Causes: Avarice, Greed, SlothUnbalanced Forces: Management of Complexity, ChangeAnecdotal Evidence: This is our main routine, here in the class called LISTENER. BackgroundFunctional Decomposition is good in a procedural programming environment.It s even usefulfor understanding the modular nature of a larger-scale application.Unfortunately, it doesn t54 translate directly into a class hierarchy, and this is where the problem begins.In defining thisAntiPattern, the authors started with Michael Akroyd s original thoughts on this topic.Wehave reformatted it to fit in with our template, and extended it somewhat with explanationsand diagrams.General FormThis AntiPattern is the result of experienced, nonobject-oriented developers who design andimplement an application in an object-oriented language.When developers are comfortablewith a main routine that calls numerous subroutines, they may tend to make everysubroutine a class, ignoring class hierarchy altogether (and pretty much ignoring objectorientation entirely).The resulting code resembles a structural language such as Pascal orFORTRAN in class structure
[ Pobierz całość w formacie PDF ]
