Explore

20-step methodology to forward generate a Java program from the UP Design Documents.

⁠

Exercise to forward generate a Java Application from a UML Design

Our workflow:

Our Enterprise Application is to add, subtract, multiple, and divide numbers. These are our Use Cases and Business Processes.

Let's make a UML design for Calculator:

Use Lexical Analysis to make ECA, and then the UML Diagram.

ECA for our SUD:

See my LucidChart diagram here:

⁠

Nouns Dictionary contains the following elements:

InputA (double primitive numeric type)

InputB (double primitive numeric type)

Output (double primitive numeric type)

Specifier for the Operator which will be a string: + - * /

Intentionalities Dictionary:

Take the 2 input double numbers → apply the specified operations →return the result to the requesting ACTOR

STD: State transition Diagram:

SSD: Domain (set of stuff we can have in our inputs: exactly 2 double numbers and an operator presented as a String { “+”, “-”, “*”, “/” }

Range is the double number corresponding to the 2 inputs and the stated rule.

PFEQ:

Complaint 1 : “ Your product does not do exponentiation”!! {this use case was not promised in the SSD STD}

Complaint 2 : “ I input 2 and 2, and the addition was 5”!! { where does this sit in our spectrum of Software quality defects?} This counts as a BUG.

How would you categorize this as a Software Defect ? Is this a bug in the program??

Verbs Dictionary:

add

substract

multiply

divide

Next step in forward generating our Enterprise Application from Design Document:

Make UML using LUCIDChart.com, and keeping an eye on our Enterprise assets Catalog:

Enterprise Application Design Heuristic:

Ask the question: What business Objects must I have in my Enterprise Domain Appication?

Number

Operation

Result

Enterprise Assets Catalog:

Consists of 3 parts:

Nouns Dictionary

Intentionalities Dictionary

Business Objects Dictionary

A Business Object is a Box, a Container, into which we park a Business Process)

— OR —

A Business Object could also be an ENTITY in the Enterprise Application Domain.

Nouns Dictionary contains the following elements:

InputA (double primitive numeric type)

InputB (double primitive numeric type)

Output (double primitive numeric type)

Specifier for the Operator which will be a string: + - * /

Intentionalities Dictionary:

Our Intentionality is “Applying the Operation”.

Take the 2 input double numbers → apply the specified operations →return the result to the requesting ACTOR

Business Objects Dictionary:

Input Number Result Number Operation

Class Joint Application Development Session TRELLO Board:

⁠

https://trello.com/invite/f23mad5234/ATTI8af378d62bc4808edee236ade58ea778F1C41E00⁠

⁠

Everyone brainstorm to design our Enterprise Business Domain Model:

What you are to do:

Access the Brainstorming Trello Board. (The class team members brain-stormed on putting this together).

Create an Account on

LucidChart.com⁠

⁠

Make a starter uml diagram in which you position boxes on the canvas to capture your understanding of the Business Objects, what data fields and methods, how they relate to each other in this Enterprise Application Domain. Learning Outcomes:

Apply Knowledge Principle:

This is the feed-in pipe for the Approprate Assignment of Responsibility Process.

Add data and behaviors to each box.

On Monday you will write Java Classes for your Enterprise Model.

Introduction and Initial Steps

Introduction:

As developers and business professionals, understanding the linkage between business requirements and the subsequent system design is crucial.

Java, being one of the most versatile and popular programming languages, provides a platform to make this linkage tangible.

In this workbook, we will walk through a 20-step methodology to create a Java program, starting from the traceability matrix, UML diagrams, and software quality metrics.

By the end, you'll not only appreciate the value of structured system design but also be able to write and test Java programs.

⁠

Step 1: Understand the Requirement

Work your Unified Process Methodology Skills. Translate the jargon and complex terminology of the Business Domain Analysis into a language that software developers understand. It's akin to deciphering a foreign language and requires the finesse of both a linguist and a coder.

Ensure that you have a comprehensive grasp of the unique requirements and features anticipated in the final software application.

Let's evaluate our understanding by addressing some Validation Questions:

Which software quality metrics are paramount considering the operational environment of our application? For example, if we're building a real-time transaction system, response time and transaction throughput might be crucial metrics.

Begin shaping your Traceability Matrix. Remember the wisdom of that ancient strategist Sun Tzu, who imparted lessons that are surprisingly applicable in this context.

Sun Tzu, in his seminal work "The Art of War," underscores the importance of keen observation and deriving actionable intelligence from subtle indicators.

⁠

He notes, "When you see dust rising in columns, it is a sign of chariots advancing; when the dust is low and widespread, it indicates infantry is on the move."

This philosophy resonates deeply with the concept of the Traceability Matrix in software engineering.

Just as observing the dust can reveal the movement and strategy of the enemy, the Traceability Matrix offers us insights into the interrelations and dependencies within our enterprise application.

It becomes a map, illustrating the ties between business requirements and the software functionalities intended to meet them.

Sun Tzu also taught, "All warfare is based on deception." In software development, the "deception" is the complexity beneath the surface.

Without tools like the Traceability Matrix, this complexity remains hidden, and developers can easily lose sight of the bigger picture.

By maintaining and consulting the oracle of the Traceability Matrix, we can "see the enemy" – that is, anticipate potential challenges and bottlenecks in our development process.

The matrix allows us to navigate the labyrinthine world of software development with foresight and strategy, much as Sun Tzu advised generals to navigate the complexities of warfare.

In essence, the Traceability Matrix enables us to externalize and organize the deep, implicit knowledge of the enterprise application.

It helps bridge the gap between the technical and business domains, ensuring that the software solution we craft aligns seamlessly with business objectives.

Through this matrix, we don't merely build software; we craft solutions that serve real-world needs, drawing inspiration from age-old wisdom to navigate contemporary challenges.

Step 2: Construct the Traceability Matrix

Begin by discerning the core functionalities, much like a general scours the battlefield, discerning the strength and position of each unit. Match each of these functionalities against the requirements. This method mirrors Sun Tzu's strategy, where he advised, "Know the enemy and know yourself; in a hundred battles, you will never be in peril."

In this stage, having no Java Code might feel like venturing into a battlefield blindfolded. But remember Sun Tzu's words: "Opportunities multiply as they are seized." Embrace the inherent uncertainty and lean into that intrinsic programmer's intuition. Trust in the innate, feelings-based knowledge. While the terrain might be unfamiliar now, the strategic vision you employ will pave the way for iterations and refinements.

By crafting this Traceability Matrix, you'll achieve clarity on how each functionality corresponds to a business requirement. It's akin to Sun Tzu's advice, "Let your plans be dark and impenetrable as night, and when you move, fall like a thunderbolt." While the matrix may initially seem complex and intricate, once understood, it will allow you to move forward with precision and decisive impact.

Drawing inspiration from Sun Tzu, it's clear that software development, much like warfare, isn't just about brute force or rote application of skills. It's about strategy, intuition, and understanding the terrain. The Traceability Matrix, in this context, is your map. Use it wisely to navigate the challenges ahead and ensure that your software aligns perfectly with the articulated business objectives.

Step 3: Introduction to UML (Unified Modeling Language)

Understand UML's core components: class diagrams, use-case diagrams, and sequence diagrams.

Recognize the symbols and notations used in UML.

Step 4: Construct Static UML Diagrams with a Unified Approach

⁠

A. Beginning with Class Diagrams

In Sun Tzu's "The Art of War," he mentions, "The supreme art of war is to subdue the enemy without fighting." This means achieving one's goals without unnecessary effort. Likewise, in software development, UML diagrams allow us to visualize the structure and interactions of our program without delving directly into coding.

Main Classes Identification: Just as a strategist discerns the key battalions and their strengths, identify the primary classes based on their functionalities. These classes form the backbone of your software, much like the vanguard in an army.

Attributes and Operations: Drawing from the Enterprise Assets Catalog, deduce the attributes (data fields) and operations (methods) for each class. Think of this process like deploying the right troops and weaponry for a specific mission.

⁠

B. Application of SOLID Principles

Sun Tzu said, "Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat." Similarly, while UML diagrams (tactics) provide a structure, the SOLID principles (strategy) ensure that this structure is robust and maintainable.

Single Responsibility Principle (SRP): A class should have one reason to change. Just as each soldier has a unique role in a battalion, each class should have a defined purpose. This inherently boosts cohesion and reduces unnecessary interdependencies.

Open/Closed Principle (OCP): Software entities should be open for extension but closed for modification. This mirrors Sun Tzu's philosophy of adapting to the enemy's strategy while maintaining your core strength.

Liskov Substitution Principle (LSP): Subtypes must be substitutable for their base types. This is akin to Sun Tzu's idea of ensuring that one unit can seamlessly replace another without disrupting the overall strategy.

Interface Segregation Principle (ISP): No client should be forced to depend on interfaces it does not use. In the words of Sun Tzu, "Do not engage an enemy more powerful than you. And if it is unavoidable and you do have to engage, then make sure you engage it on your terms, not on your enemy's terms."

Dependency Inversion Principle (DIP): High-level modules should not depend on low-level ones; both should depend on abstractions. By following this, you ensure a level of separation, reminiscent of Sun Tzu's approach to orchestrating larger strategies without being bogged down by individual skirmishes.

⁠

C. Knowledge Principle and Appropriate Assignment of Responsibility

The Unified Process highlights the Knowledge Principle: the object most knowledgeable about a business process should be tasked with delivering that process. This mirrors Sun Tzu's teachings where he emphasizes leveraging the strengths of individual units for the larger strategy.

For instance, a unit skilled in reconnaissance would not be used as the main assault force. Similarly, in software, a data-heavy class would not be primarily responsible for UI interactions. By assigning responsibilities appropriately, you ensure that each class or object operates at its peak efficiency.

⁠

Conclusion:

Software development and warfare might be worlds apart, but the strategic depth required in both fields has striking parallels. Sun Tzu’s heuristics, combined with the Unified Process and SOLID principles, provide a comprehensive toolkit for aspiring software developers. As students chart their journey through the intricate realms of software architecture, the wisdom of "The Art of War" can serve as a guiding beacon, ensuring clarity, purpose, and efficiency in design.

Step 5: Define Class Relationships

Determine relationships between classes: Association, Aggregation, Composition, Inheritance.

Assign multiplicities for these relationships.

Step 6: Object-Interaction Diagrams

Create sequence diagrams to showcase the flow of operations between objects of classes.

This will provide a clear interaction path between various system components.

Step 7: High-Cohesion and Low-Coupling

Ensure each class has a single responsibility (high cohesion).

Minimize interdependencies between classes (low coupling).

Step 8: Software Quality Metrics

Familiarize yourself with basic software quality metrics such as cyclomatic complexity, depth of inheritance, and class coupling.

These metrics provide insights into the maintainability, reliability, and performance of your software.

⁠

Lab Exercise 1:

Given a basic business requirement, create a traceability matrix and draft a UML class diagram.

Epoch 2: Designing, Implementing, and Testing

⁠

Step 9: Setting up Development Environment

Install the required Java Development Kit (JDK).

Setup Integrated Development Environment (IDE) like Eclipse, IntelliJ, or NetBeans.

Install JUnit plugin/framework for unit testing.

Step 10: Convert UML to Java Code Structure

Using your UML class diagrams, create empty Java classes with the identified attributes (data fields) and methods.

Ensure that classes mirror the relationships (association, inheritance, etc.) from the UML.

Step 11: Writing Methods and Logic

Fill in the logic for each method defined in your classes.

Use your sequence (object-interaction) diagrams to understand the flow of data and operations.

Step 12: Implementing High Cohesion and Low Coupling

Keep methods and class functionalities specific.

Utilize design patterns where necessary to ensure minimal dependencies between classes.

Step 13: Basic Java Program Testing

Conduct manual tests by running the main program.

Ensure each class and method behaves as expected.

Step 14: Introduction to JUnit

Understand the basics of JUnit – a widely-used testing tool for Java.

Learn how to write JUnit tests for individual methods.

Step 15: Write JUnit Tests

For each class method, write a JUnit test.

The goal is to ensure every method's functionality is validated against expected behavior.

Step 16: Run JUnit Tests

Execute the JUnit tests using your IDE.

Make sure all tests pass. If not, debug the failed tests and make necessary code corrections.

⁠

Lab Exercise 2:

Given a partial Java program, implement missing logic using UML diagrams as a guide, and then write and execute JUnit tests to validate the program's functionality.

Class Interaction Testing, Refining, and Conclusion

⁠

Step 17: Class Interaction Testing

Understand the importance of testing how classes interact. It's not just about individual units but also about the collaboration of units.

Use your object-interaction diagrams as a blueprint to check if objects are interacting as visualized.

Step 18: Refactor and Optimize

Refactoring: Based on your test outcomes and insights, make structural improvements without changing external behavior.

Optimization: Make your code more efficient. This could involve reducing redundancy or improving algorithmic efficiency.

Step 19: Software Quality Metrics Re-evaluation

After refining your code, re-evaluate it with the software quality metrics introduced earlier.

Compare the metrics before and after refactoring to ensure improvements in maintainability, reliability, and performance.

Step 20: Documentation and Reflection

Document your Java program: This includes inline comments, method descriptions, and class overviews.

Reflect on the entire process. Understand how starting with the traceability matrix and UML diagrams guided your development process and how it aided in ensuring the program meets business requirements.

⁠

Lab Exercise 3:

Collaborate in teams to test the interaction of classes developed by another group. Provide feedback.

Refactor a provided Java code snippet to demonstrate a better understanding of high cohesion and low coupling principles.

Document a given Java class, describing its purpose, methods, and attributes.

⁠

Conclusion:

Congratulations on successfully walking through the 20-step methodology to architect, write, and test a Java program, starting from business requirements and forward-generating using UML diagrams and software quality metrics!

Always remember the importance of planning and design. A well-structured initial design not only makes coding easier but also ensures the software aligns with business goals. The skills and methodologies you've practiced here are foundational for an IT developer and will serve you well in real-world applications.

As you continue on your journey in software development, aim to delve deeper into each topic, practice consistently, and always stay curious. Best of luck!

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.