Java Source File Structure


Managing Project Complexity

Software engineers generally encounter two types of project complexity: conceptual and physical. All programming projects exhibit both types of complexity to a certain degree, but the approach and technique used to manage small-project complexity will prove woefully inadequate when applied to medium, large, or extremely large programming projects. This section discusses both types of complexity, and suggests an approach for the management of each.

Conceptual Complexity

Conceptual complexity is that aspect of a software system that is manifested in, dictated by, and controlled by its architectural design. A software architectural design is a specification of how each software module or component will interact with the other software components. A project s architectural design is the direct result of a solution approach conceived of by one or more software engineers in an attempt to implement a software solution to a particular problem domain. In formulating this solution, the software engineers are influenced by their education and experience, available technology, and project constraints.

An engineer versed in procedural programming and functional decomposition techniques will approach the solution to a programming problem differently from an engineer versed in object-oriented analysis and design techniques. For example, if a database programmer versed in stored-procedure programming challenged an Enterprise Java programmer to develop a Web application, the two would go about the task entirely differently. The database programmer would place business logic in database stored procedures as well as in the code that created the application web pages. The Enterprise Java programmer, on the other hand, would create a multi-tiered application. He would isolate web-page code in the web-tier, and isolate business logic in the business-tier. He would create a separate data-access tier to support the business-tier and use the services of a database application to persist business objects.

By complete chance, both applications might turn out looking exactly the same from a user s perspective. But if the time ever came to scale the application up to handle more users, or to add different application functionality, then the object-oriented, multi-tiered approach would prove superior to the database-centric, procedural approach. Why?

The answer lies in whether a software architecture is structured in such a way that makes it receptive and resilient to change. Generally speaking, procedural-based software architectures are not easy to change whereas object-oriented software architectures are usually more so. The co-mingling of business logic with presentation logic, and the tight coupling between business logic and its supporting database structures, renders the architecture produced by the database programmer difficult to understand and change. The object-oriented approach lends itself, more naturally, to the creation of software architectures that support the separation of concerns. In this example, the web-tier has different concerns than the business-tier, which has separate concerns from the data-access tier, etc.

However, writing a program in Java, or in any other object-oriented programming language does not, by default, result in a good object-oriented architecture. It takes lots of training and practice to develop good, robust, change-receptive and resilient software architectures.

Managing Conceptual Complexity

Conceptual complexity can either be tamed by a good software architecture, or it can be aggravated by a poor one. Software architectures that seem to work well for small to medium-sized projects will be difficult to implement and maintain when applied to large or extremely large projects.

Conceptual complexity is tamed by applying sound object-oriented analysis and design principles and techniques to formulate robust software architectures that are well-suited to accommodate change. Well-formulated object-oriented software architectures are much easier to maintain compared to procedural-based architectures of similar or smaller size. That s right large, well-designed object-oriented software architectures are easier to maintain and extend than small, well-designed procedural-based architectures. The primary reason for this fact is that it s easier for object-oriented programmers to get their heads around an object-oriented design than it is for programmers of any school of thought to get their heads around a procedural-based design.

The Unified Modeling Language (UML)

The Unified Modeling Language (UML) is the de facto standard modeling language of object-oriented software engineers. The UML provides several types of diagrams to employ during various phases of the software development process such as use-case, component, class, and sequence diagrams. However, the UML is more than just pretty pictures. The UML is a modeling meta-language implemented by software-design tools like Embarcadero Technologies Describe and Sybase s PowerDesigner. Software engineers can use these design tools to control the complete object-oriented software engineering process. Java For Artists uses UML diagrams to illustrate program designs.

Physical Complexity

Physical complexity is that aspect of a software system determined by the number of design and production documents and other artifacts produced by software engineers during the project lifecycle. A small project will generally have fewer, if any, design documents than a large project. A small project will also have fewer source-code files than a large project. As with conceptual complexity, the steps taken to manage the physical complexity of small projects will prove inadequate for larger projects. However, there are some techniques you can learn and apply to small programming projects that you can in turn use to help manage the physical complexity of large projects as well.

The Relationship Between Physical and Conceptual Complexity

Physical complexity is related to conceptual complexity in that the organization of a software system s architecture plays a direct role in the organization of a project s physical source-code files. A simple programming project consisting of a handful of classes might be grouped together in one directory. They might all be easily compiled by compiling every class in the directory at the same time. However, the same one-directory organization would simply not work on a large project with teams of programmers creating and maintaining hundreds or thousands of source files.

Managing Physical Complexity

You can manage physical complexity in a variety of ways. Selecting appropriate class names and package structures are two basic techniques that will prove useful not only for small projects, but for large projects as well. However, large projects usually need some sort of configuration-management tool to enable teams of programmers to work together on large source-code repositories. CVS and PVCS are two examples of configuration-management tools. The projects in this book do not require a configuration-management tool. However, the lessons you will learn regarding class naming and package structure can be applied to large projects as well.

Maximize Cohesion Minimize Coupling

An important way to manage both conceptual and physical complexity is to maximize software module cohesion and minimize software module coupling.

Cohesion is the degree to which a software module sticks to its intended purpose. A high degree of module cohesion is desirable. For example, a method intended to display an image on the screen would have high cohesion if that s all it did, and poor cohesion if it did some things unrelated to image display.

Coupling is the degree to which one software module depends on software modules external to itself. A low degree of coupling is desirable. Coupling can be controlled in object-oriented software by depending upon interfaces or abstract classes rather than upon concrete implementation classes. These concepts are explained in detail later in the book.




Java For Artists(c) The Art, Philosophy, and Science of Object-Oriented Programming
Java For Artists: The Art, Philosophy, And Science Of Object-Oriented Programming
ISBN: 1932504052
EAN: 2147483647
Year: 2007
Pages: 452

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net