Sunteți pe pagina 1din 8

Tanya Churaman Team 49: Aquatic Donkeys M11

Introduction:
Cay Horstman initially faced the problem of his exasperation with the object-oriented design curriculum.
For the first level Computer Science programming course, students would begin their education by first learning
how to create a single class. These students would not touch upon object-oriented design until very later in their
education, perhaps in a senior level software engineering course. However, in this course, the students were still not
learning the importance nor the application of object-oriented design. Instead, students were receiving a brief
runthrough of what UML diagrams were and other various design patterns. This brief coverage of the material does
not actually allow the students to achieve the learning goals of design methodology, design notation, and standard
principles and practice in design. Thus, Horstmann designed his own textbook for a semester-long course for
students who are already knowledgeable in programming in Java and basic data structures. The book details over the
principles of object-oriented design and design patterns. The design patterns are explained through familiar
examples that students would be able to find application and meaning to in order to boost understanding and
applicability of the design patterns.
In this textbook, Horstman included many aspects of UML: “class diagrams, sequence diagrams, and a
variant of object diagrams that shows Java object references.” In addition to just providing a textbook that would
teach students these important object-oriented design principles, Horstman wanted students to actually apply their
knowledge by drawing their own diagrams. Current technology at the time were both expensive and too complicated
for students to learn and use. Other options had many limitations or bugs that prevented students from optimal use of
creating the diagrams. Thus, the author took matters into his own hands by creating Violet -- a simple editor that
would serve as both a useful and easy framework for students and teachers to generate, modify, and understand the
diagrams they were creating.

Description:
Horstman covers many aspects of the architecture of Violet. He covers the Graph Framework, the Plugin
Architecture, Java WebStart, and Javabeans properties and persistence. Violet implements a simple and general
graph framework that allows for users to create nodes and edit the edges of arbitrary shapes. The nodes serve the
purpose of representing the classes, objects, activation bars, etc. for the diagrams that the users are creating. The
edges serve the purpose of being the “edges” or sides of the arbitrary shapes and also displaying the
entity-relationship model. This model highlights the relationship between entities - the objects of the model and how
they relate and depend on each other (Rouse). This framework implements the Prototype Design Pattern. This
design pattern embraces the concept of copying an object that already exists in opposition of creating a new object
with the same attributes repeatedly. The original object serves as the prototype that contains its state while the copies
or “clones” can have its attributes changed if necessary to mirror the needs of the user. Below is a figure that
displays a simple graph created in the graph editor of Violet. The black and white circles serve as nodes that are
connected by edges to display some sort of relationship between the entities (nodes). The Prototype Design pattern
allows for the edges and nodes to be copied multiple times rather than being created from scratch for every instance,
thus saving time and resources (Kumar). The user can then just alter attributes of the copies of the prototype
(Kumar). For example, in the picture below, the user has changed the color of the circle nodes. Instead of having all
black nodes, the user altered the copies of the original node by changing its color to white. This software also
implements the Java 2D library to allow for the user to apply various graphic properties to their objects (nodes,
edges, etc.), such as applying colors, drawing images, transforming objects, etc. (“Trail: 2D Graphics”) .

This picture is an example the 2D Graphics for the Graph Framework.


Tanya Churaman Team 49: Aquatic Donkeys M11
Violet also implements a Plugin Architecture. This architecture enables users to easily implement a new
type of diagram. Users need not understand the framework of Violet; they only need to have an understanding of the
implementation of a graph, node, and edge. Those who wish to create a new type of diagram just needs to provide a
java jar file containing the implementations of the graph, node, and edge. Once this jar file is dropped into the
plugins directory, the users are able to create their own projects with their own specially made diagrams. As shown
in the image below, the basic diagrams that were a part of Horstman’s vision for users to easily create -- UML
diagrams, sequence diagrams, class diagrams, etc. -- are implemented via the plugin architecture. An advantage of
this technique is that users have the ability to add their own functionality to meet their needs without having access
to the source code (“Plug-in Architectures”). Thus, the creator(s)’s software is protected and unaltered, and the user
can customize their projects with extra features easily (“Plug-in Architectures”).

As seen in this picture, the basic diagrams that the creator wanted users to be able to create were implemented via
Plug-in Architecture.

Java WebStart enables for an application to be launched from a web browser. This technology allows for
users to carrying out functions such as loading, saving, and printing files. A great advantage of this technology is its
security. This technology eradicates the need for users of making the judgement of whether a digital certificate is
valid and the results of trusting this application. Instead, Java Webstart receives the stream object without having
access to the whole filesystem. As a result, users are protected from having outside code with viruses affecting their
files (“Java Web Start and Security”).
Another implementation of Violet is Javabeans. Javabeans are classes that encapsulate many objects all into
one object considered the bean (“Trail: JavaBeans(TM)”). The main importance of Javabeans to this software is the
getters and setters. This property of Javabeans enables editing of the properties or attributes of objects. For example,
if users wanted to set the color of their rectangular nodes from red to green, Javabeans would simply use two
methods -- getColor() and setColor(color) -- to modify the attributes of these nodes for the project. Javabeans also
served the purpose of persistence for Violet. In order for users to be able to save their projects and reopen them at a
later time, an XML file was created to ensure persistence through the means of object serialization via object
modification and construction statements.
After analyzing the architecture of this software, the criteria for packaging appears to be for the purpose of
maintenance. In the GitHub repository, “violetumleditor”, there is the folder labeled “ violet-framework.” The main
classes for Violet is contained in this folder (de Pellegrin). Upon expansion of the previously mentioned folder, we
get down to two main folders -- “framework” and “product.” The framework folder contains classes that serve the
purpose of providing functions that can be applied to the diagrams users create, such as printing and other file
management services (de Pellegrin). The product folder contains classes that focus more on the actual building and
displaying of the user’s diagrams (de Pellegrin). Thus, the packaging of this software could be thought of as
maintenance rather than reuse since the grouping of classes focus more on the similarity of classes’ functionality.
Thus, by grouping classes that focus on managing the diagrams and other classes that focus on creating diagrams,
Tanya Churaman Team 49: Aquatic Donkeys M11
the classes are kept in an orderly and systematic fashion that focus more on maintaining functionality rather than
reuse of code.

Analysis:
The design principle SOLID stands for: Single Responsibility Principle (SRP), Open/Closed Principle
(OCP), Liskov Substitution Principle (LSP), Interface Segregation Principle (ISP), and Dependency Inversion
Principle (DIP) (Ramirez). GRASP (General Responsibility Assignment Software Patterns) are design principles
with the goal of guiding developers in the assignment of objects in collaboration (Rao). GRASP is composed of the
principles/patterns: Creator, Information Expert, Low Coupling, Controller, High Cohesion, Indirection,
Polymorphism, Protected Variations, and Pure Fabrication (Rao).
SRP states that a class should have one function/job, meaning the class only has one reason to be changed
(Ramirez). Violet emulates this principle by having multiple classes to each carry out a specific function rather than
just having one class with all the methods of functionality. For example, for the Sequence Diagram Plugin, the
github page shows many classes that depict the breakdown of the functionality. We have the
“SequenceDiagramPlugin.java” class that focuses on the actual plug-in functionality of the sequence diagram, the
“SequenceDiagramGraph.java” that focuses on adding a node and defining its edges, the
“SequenceDiagramConstant.java” that focuses on the constant properties of the diagram, and there are multiple
classes in the “edge” and “node” folder that divide up the tasks of creating the node/edge and modifying its
attributes. This application of SRP is applied across most of the software; this application was just one example.
Below are pictures of the source code described above to provide visual representation.

This class is the SequenceDiagramConstant class that focuses on the constant properties of the diagram.

This class is the SequenceDiagramPlugin class that focuses on the actual plug-in functionality of the sequence
diagram.
Tanya Churaman Team 49: Aquatic Donkeys M11

This class is the SequenceDiagramGraph class that focuses on adding a node and defining its edges.

This example also emulates the High Cohesion Pattern of GRASP. The goal of High Cohesion is to contain
“related responsibilities into one manageable unit” (Rao). This principle means that objects should be made easy to
maintain through having clearly defined purposes and functionality, thus implicating that classes should have one
specific function or job (Gibbs). This pattern is similar to SRP from SOLID. As mentioned in the previous
paragraph, Violet contains multiple classes to each carry out a specific function rather than just having one class
with all the methods of functionality. Referring back to the example, the classes “SequenceDiagramPlugin.java”,
“SequenceDiagramGraph.java”, and “SequenceDiagramConstant.java” each contain one type of functionality, thus
creating one manageable unit each. Then, these classes come together to interact to allow for the user to create a
Sequence Diagram. This application of High Cohesion and SRP is displayed all throughout the software for each
type of diagram that the user can make. The functionality is broken down into multiple classes with clearly defined
roles, thus not having one big class with all types of functionality that could result in later confusion and
unmanageability. A result of High Cohesion is another pattern of GRASP -- Low Coupling (Rao). Low Coupling
examines the relationship of how strongly connected objects are (Rao). Violet implements Low Coupling by having
multiple classes grouped together, thus creating a small amount of groups that need to interact with each other. Let’s
use the Sequence Diagram Plugin again since we have been referencing it for this whole paragraph. As shown in the
picture below, this plugin is broken into three groups: Node, Edge, and Diagram. The Node folder contains multiple
classes that interact with each other when the user creates various nodes for the diagram. The Edge folder contains
multiple classes that create edges to create an entity relationship between nodes. The diagram classes work with
creating the whole diagram. The coupling of the classes into these three groups allow for Low Coupling to be
enacted. Thus, changes to the nodes won’t affect what happen to the edges the user creates. The overall diagram
itself is not affected when the user makes changes to the nodes or the edges, thus the benefits of Low Coupling
coming through. Like High Cohesion and SRP, Low Coupling is displayed all throughout the software for each type
of diagram that the user can make.

The three classes outside of the edge and node folders represent the diagram classes that work to create the whole
diagram.
Tanya Churaman Team 49: Aquatic Donkeys M11

These classes were inside the edge folder shown earlier. These classes are grouped together in this folder to serve the
purpose of creating edges to create an entity relationship between nodes.

These classes were inside the node folder shown earlier. These classes are grouped together in this folder to serve
the purpose of interacting with each other when the user creates a node for the diagram.

LSP states that every subclass should have the property of being substitutable for the parent class it is
extended from (Ramirez). To further elaborate, the subclass should contain methods that override that of its parents
in order to maintain functionality (Ramirez). Violet uses this principle throughout the software for each of the
diagrams that the user can create. For each diagram, there are various types of nodes - each of which are extended
from a parent class. These children nodes have their own overridden methods with different implementations to fit
the needs of the users as they create their diagram, thus not having to depend on the parent class and result in the
possible case of breaking functionality on the users’ end. In Violet, let’s use the classes “BallAndSocketNode.java”
and “PackageNode.java” from the “violetplugin-classdiagram” folder of source code from GitHub. Both of these
classes extend the parent class “ColorableNode.java.” Both of these classes also contain the method
createShape(double contentWidth, double contentHeight). Both classes have to override this method from the parent
class with its own implementation rather than calling the parent method because this method creates the shape for
the Ball and Socket Node and the Package Node differently. Thus, the parent method createShape cannot be applied
to both “PackageNode.java” and “BallAndSocketNode.java.” Instead, a different implementation of the method
must be created for both node classes in order to substitute for its parent class. This application of LSP is also an
example of Polymorphism from GRASP. Polymorphism can be defined as one thing having the ability to perform in
different ways (Gibbs). Again, the functionality of the createShape method varies, depending on the type of node
being created. Polymorphism results in new variations of an object being easier to handle (Rao). Rather than having
the parent class of ColorableNode to account for every variation of a node, the subclasses can take the responsibility
of handling the necessary implementations. Below is the source code of the two implementations of this method.

This method is the createShape method for the BallAndSocketNode class. This implementation of the method is
vastly different to the createShape method for the PackageNode class (shown below).
Tanya Churaman Team 49: Aquatic Donkeys M11

This method is the createShape method for the PackageNode class. The implementation is different than that of the
BallAndSocketNode because these classes create two different types of nodes with different attributes. Thus, these
children node classes of ColorableNode class must override the parent method of createShape to fit the functionality
of the program.

FURPS (Functionality, Usability, Reliability, Performance, Security/Sustainability) is an acronym that can


be used as a measurement for critiquing the quality of a software. Functionality essnetially measures if the software
accomplishes what it should (Eeles). Violet is meant for the purposes of allowing students and teachers to easily
create diagrams of object-oriented design. The current architecture of the software allows for users to utilize the
graph framework to create nodes and edges to create entity relationships between objects (such as classes).
Javabeans allows for users to be able to save their diagrams for further use or work. The Plugin Architecture also
allows for users to create their own types of diagrams easily. Thus, the architecture of Violet meets the Functionality
aspect by allowing users to create diagrams - whether it be via the use of the objects given by the software or
creating it purely from scratch with their classes - while also allowing them to save and modify their work. Usability
refers to the software containing user interface with aesthetics and consistency that promote efficiency and
effectiveness. The image below displays how the user interface is very simplistic in such that it allows users to pick
the diagram they wish to create, and then, they can start building their diagrams by dragging and dropping the
elements they need. These elements are labels so the user is not confused on what element of the diagram
symbolizes what. Reliability refers to availability (system uptime), accuracy, and the ability to recover from failure
(Eeles). Violet is a durable software that implements JavaWebstart to protect the users’ files and allows the user to
create diagrams that come with the software or implement their own diagrams. Performance refers to the efficiency,
scalability, and response of the software (Eeles). The scalability of Violet is vast. The software can be used for
beginners to create simple diagrams to capture the object-oriented design principles of their coding projects, or
experts can implement their own diagrams by creating their own classes and putting them into the plugins directory
provided by the Plugin Architecture of Violet. To implement the Security aspect of FURPS, Violet used Webstart to
eliminate the need for users of deciding whether a digital certificate is valid and the results of trusting this
application, thus reducing the chance of having outside code with viruses corrupting the users’ files.
Tanya Churaman Team 49: Aquatic Donkeys M11

Conclusion
Overall, the architectural design of Violet is exemplary. The Graph Framework and the Plugin Architecture
allows for users’ to either easily create diagrams to represent object-oriented design principles through a drag and
drop platform or create their own elaborate diagrams through the creation of their own jar files. The software also
implements important design principles that add to the functionality and simplicity of the program. There are
multiple classes in order to divide functionality rather than overcomplicating a few classes, thus allowing for
coupling of classes and reuse of code. In essence, this software implements many design principles to ensure quality
and easy to understand code that results in a successful program that allows for users to accomplish their goal of
creating diagrams to model their programs.
Tanya Churaman Team 49: Aquatic Donkeys M11
Works Cited

de Pellegrin, Alexandre. “Want to Contribute? Welcome to the Developer Guide!” ​Violet UML Editor : Easy to Use,
Completely Free​, FCKwiki, alexdp.free.fr/violetumleditor/page.php?id=en%3Adeveloperguide.

Eeles, Peter. “Capturing Architectural Requirements.” ​ DeveloperWorks​, IBM, 15 Nov. 2005,


www.ibm.com/developerworks/rational/library/4706.html.

Gibbs, Martin. “GRASP Design Patterns in Object-Oriented Design.” ​Study.com​, Study.com,


study.com/academy/lesson/grasp-design-patterns-in-object-oriented-design.html.

Horstmann, Cay. “Violet.” ​The Architecture of Open Source Applications​, www.aosabook.org/en/violet.html.

“Java Web Start and Security.” ​The Java Tutorials​, Oracle: Java Documentation,
docs.oracle.com/javase/tutorial/deployment/webstart/security.html.

Kumar, Saket. “Prototype Design Pattern.” ​GeeksforGeeks​, 12 July 2017,


www.geeksforgeeks.org/prototype-design-pattern/.

“Plug-in Architectures.” ​Code Loading Programming Topics​, Apple Inc, 16 Dec. 2013,
developer.apple.com/library/content/documentation/Cocoa/Conceptual/LoadingCode/Concepts/Plugins.htm
l.

Ramirez, Cristian. “S.O.L.I.D The First 5 Principles of Object Oriented Design with JavaScript.” ​Medium​, Medium,
9 Jan. 2017,
medium.com/@cramirez92/s-o-l-i-d-the-first-5-priciples-of-object-oriented-design-with-javascript-790f6ac
9b9fa.

Rao, Danya. ​GRASP Design Principles​. University of Colorado Boulder,


www.cs.colorado.edu/~kena/classes/5448/f12/presentation-materials/rao.pdf.

Rouse, Margaret. “What Is Entity Relationship Diagram (ERD)?” ​SearchDataManagement​, TechTarget,


searchdatamanagement.techtarget.com/definition/entity-relationship-diagram-ERD.

“Trail: 2D Graphics.” ​Trail: 2D Graphics (The Java™ Tutorials)​, Oracle: Java Documentation,
docs.oracle.com/javase/tutorial/2d/.

“Trail: JavaBeans(TM).” ​The Java Tutorials​, Oracle: Java Documentation,


docs.oracle.com/javase/tutorial/javabeans/.

“Violetumleditor/Violetumleditor.” ​GitHub​,
github.com/violetumleditor/violetumleditor/tree/master/violet-framework/src/main/java/com/horstmann/vio
let.

S-ar putea să vă placă și