Software Design – Selcote

4 Practical Books for Software Architecture

A lot of senior developers, who aspire to become software architect or solution architect, like what can they do to become a software architect? Which books, resources, or certifications can help ?

And how much experience you need to become a software architect etc.

So, I am suggesting some books to read to expand their knowledge base and look at the software from architecture and design perspective, and this article is a compilation of many of such suggestions.

Since a lot of books can confuse, I have only select 4 best and must-read books from the software architect’s perspective.

1- The Architecture of Open Source Applications

In this book, the authors of dozen open source applications explain how their software is structured, and why ?

What are each program’s major components?

How do they interact ?

And what did their builders learn during their development?

In answering these questions, the contributors to these books provide unique insights into how they think.

If you are a junior developer, and want to learn how your more experienced colleagues think, these books are the place to start.

If you are an intermediate or senior developer, and want to see how your peers have solved hard design problems, these books can help you too.

2- 97 Things Every Software Architect Should Know: Collective Wisdom from the Experts

In this technical book, today’s leading software architects present valuable principles on key development issues that go way beyond technology.

More than four dozen architects, including Neal Ford, Michael Nygard, and Bill de hora, offer advice for communicating with stakeholders, eliminating complexity, empowering developers, and many more practical lessons they’ve learned from years of experience.

Among the 97 principles in this book, you’ll find useful advice such as:

Don’t Put Your Resume Ahead of the Requirements (Nitin Borwankar) Chances Are,

Your Biggest Problem Isn’t Technical (Mark Ramm) Communication Is King.

Clarity and Leadership, Its Humble Servants (Mark Richards),

Simplicity Before Generality, Use Before Reuse (Kevlin Henney),

For the End User, the Interface Is the System (Vinayak Hegde),

It’s Never Too Early to Think About Performance (Rebecca Parsons),

To be successful as a software architect, you need to master both business and technology.

This book tells you what top software architects think is important and how they approach a project.

If you want to enhance your career, 97 Things Every Software Architect Should Know is essential reading.

3- Beautiful Architecture: Leading Thinkers Reveal the Hidden Beauty in Software Design

What are the ingredients of robust, elegant, flexible, and maintainable software architecture?

Beautiful Architecture answers this question through a collection of intriguing essays from more than a dozen of today’s leading software designers and architects.

In each essay, contributors present a notable software architecture, and analyze what makes it innovative and ideal for its purpose.

4-The Design of Design: Essays from a Computer Scientist

Effective design is at the heart of everything from software development to engineering to architecture.

But what do we really know about the design process? What leads to effective, elegant designs?

The Design of Design addresses these questions.

Conclusion:

That’s all about some of the best books for a software architect, technical leads, and solution architect.

If you want to move the next step in your career towards an end goal of becoming a software architect, these are the books to read to expand your vision and knowledge.

Some related articles you might interest in :

1- Professional Illustrate the Specifications before Jumping to Code

2- The Design Cannot Be Taught

3- Class Diagram is The Most Popular and Complex

4- How To Be a Great Problem-Solver Software Engineer

5-The Key to Becoming a Professional Software Engineer

Professional Illustrate the Specifications before Jumping to Code

If you want to design a program, you might want to know first what the program supposed to do.

These instructions are called specifications and they might come from the customer, the end user or the analyst team.

They might be provided it to you in informal text, in a structured document, or using a formal mathematical notation.

In this article I will focus on Mathematical notation.And I will use two notations,mathematical logic and OCL.

The brand of mathematical logic we will use is called by various names,including first order logic,FOL,and predicate calculus.

FOL, enables you to precisely express propositions, combine them using like and and, or or not.

and quantify them using logical connectives using the operators for all and there exists.

OCL,Object constraint language,which is a part of UML.

OCL,provides a syntaxe for FOL that can be used to annotate UML diagrams.

Typically break the specification into three pieces,called the signature,the precondition,and the postcondition.

Signature:

Gives the name of the program,the names and types of the input arguments and the name and the type of the results.

Example:

Vector<int> Y = SORT(Vector<int> X).

The sort takes a single argument named X that has the datatype Vector<int> and produces a result Vector Y.

X and Y have explicit names so we can use them in the pre and post conditions.

Precondition:

We have to make sure that the x element we are passing there, is not negative.So,x > 0.

We are specifying the behavior of the function in terms of what does this function mean when it gets expected arguments?

If you wanted to have a variant.which worked on any argument.But raise an exception or produced a return code if x was less than 0. We can specify that as well.

PostCondition:

The postcondition is also an insertion.

It says what must be true about the output produced by a function.

Typically this means expressing how the output relates to the input.

Postconditions for Sort:

1- The output vector Y must be ordered.

2- The contents of Y must be the same as the content X.

OCL (Object Constraint Language)

So, when we look at UML we look at diagrams.But, diagrams don’t tell the whole story.There are places in the specifications and the designs of your system where you need more details. And that is what OCL was designed to provide to designers.

OCL, is a language,it’s not a programming language.It’s a specification language. It’s a declarative,it’s strongly typed,and it allows you to specifiy the functional details of system properties.

OCL consists of means to express constraints plus some collection classes add the ability to navigate around the various classes of relationships in your diagrams.

Constraints + collection classes + UML diagram navigation.

OCL is a mature technology is an official part of UML and supported by various tools.such Rational Rose,ArgoUML,Eclipse,Poseidon,Enterprise Architect and so on.

Why Do we Need OCL ?

The diagrams are great, at describing structural relationships and behavioral descriptions.

But, there times when you need to be more precise, particularly about the functional details.

Of exactly, what it means for this particular component to do this particular task.

OCL extends UML, with :

1- Class invariance.

2- Descriptions, precise descriptions of operations in terms of pre and post conditions.

3- They can also be used as guards on transitions in state chart diagrams.

Conclusion:

There are three aspects of OCL to be aware of : It’s declarative, it’s not a procedural language, it’s not a programming language. it’s a way of specifiying properties.

As a bonus from this article, I want to share with you some books,that changed my life in the domain of software design engineering:

1- Clean Code: A Handbook of Agile Software Craftsmanship

2- Clean Architecture: A Craftsman’s Guide to Software Structure and Design (Robert C. Martin Series)

3-The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition

The Design Cannot Be Taught

Design is all about making decisions.Generally trading off among nonfunctional criteria.

Various sources can form this decision,such as the customer,the end user,technology specifications,and competitors products.

Sometimes,However,a more detailed analysis is required.

Example of such devices include simulations, prototypes, and design studies.

In this article I will focus on design studies.

When an architect design a building, often one of the early steps is to undertake a design step.

This takes the form of series of scale models where different approaches are explored in order to get a better feel for the design space, which is the range of possibilities available as solutions.

The same approach is used in other areas of design, such as cars, planes and even clothing.

A design study is a rigorous and systematic evaluation of the factors that influence a design.

It should begin with determination of relevant criteria,metrics, and threshold.

How they are measured ?

What measurement values are deemed satisfactory ?

The study itself consists of a comparison of the various possible approaches in each approach is measured against the predetermined criteria.

The process of doing a design study helps the designer explore a space of possibilities.

“The design can’t be taught “

But,what can be taught is the surrounding skills such as analysis, modeling and evaluation.

Instead, the design must be learned.Learned by doing.

You can think of a design study as an empirical scientific experiment. As such the research questions, subjects of study, experimental conditions, methods, tools, metrics, independent variables, data collection,statistical analysis and conclusions.

The overall goal of a design is repeatability. That is ,someone else should be able to take your study report,use it to recreate the study conditions,and reach the same conclusions that you did.

There are 9 steps for a design study :

1- Context

It provides background and motivation for the study.So,the reader who is not familiar with class or the project can make sense of what you have written.

It should also define any specialized vocabulary necessary for the reader to understand.

2- Research questions

The design study examines the trade-offs between various non-functional requirements.

For example,space and time.

Each trade-off can be expressed in the form of a question,such as :

How are execution times and memory footprint effected as the amount of pre-processing computations vary ?

Each question should be formulated in a neutral fashion.

3- Subject

A design study compares multiple subjects.

Each subject, should be briefly described differentiating it from the other subjects.

4- Experimental Conditions

A software design study normally means running several versions of a program, making measurements and evaluating the results.

These programs running on computers configured with resources.

Such as their number of cores, the amount of RAM, their clock speed and potentially the networking that networks them together.

Experimental conditions describes also the environment in which the study will take place.

Such as the machines, their models, operating systems, programming languages, any virtual machines and their versions…

5- Variables

The design studies themselves have to be designed. In particular the independent variables must be identified and appropriate metrics specified.

Design studies like experiments, allow designers, like scientifics, to alter conditions and note results.

It describes variables, both independent and dependent variables, the units of measure and how the research questions address them.

6- Method

This includes the number of trials, measurement devices and tools, randomization technique were appropriate, and number of significant digits you used in your measurements and so on.

This should also include an explicit subject will be run, and the argument used for each trials.

For example: if you were studying the relationship of performance to grid size, you would want to specify what different grid sizes you will be using.

The method should also describe any statistical technique you will use, for example linear regression

7- Results

The point of conducting a design study is to produce data.

It represents the data collected and their statistical analysis.

8- Discussion

The opportunity to interpret the data you collected and provide a discussion of its implication.

This often means offering an explanation for of any unexpected values you see.

Also, allows you to reflect on the experimentation itself.Including any suggestions,any suggested further work or for improving the study process itself.

9- Conclusions

Its about summarizing the result and draw conclusions.

It provides explicit answers, to the research questions, you raised in the second step.

Conclusion

As I said, the design cannot be taught, you have to learn it.And I want you to learn it by projects.

I encourage you to invest energy and time in the projects and to think systematically about the design issues that each one of them raises.

Express that systematic thinking in the form of some experiments that you run,then write up those experiments in the form of a report.

I think by doing this it will force you to reflect upon the design process, and thereby, make it much more real for you.

And you, what do you think about the design process ?

As a bonus from this article, I want to share with you some books,that changed my life in the domain of software design engineering:

1- Clean Code: A Handbook of Agile Software Craftsmanship

2- Clean Architecture: A Craftsman’s Guide to Software Structure and Design (Robert C. Martin Series)

3-The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition

Class Diagram is The Most Popular and Complex

In this article,I am going to talk about how to express the results of problem understating using Unified Modeling Language (UML).

In particular UML’s Class Model Diagram, which is the most popular form of the UML.

As I have talked in the previous article about OOA(Object Oriented Analysis),the process by which you can begin to understand the problem you are trying to solve.

Besides,class diagram is popular, it’s the most complex of the diagramming types in UML.

UML class diagram is called also static Structure Diagrams.

Classes have features.by that I mean its attributes and its operations.

Classes exist in the real world,features exist inside the computer.

Example of classes:

I want to mention here for reservation class,that responsibilities and exceptions are not part of the UML.

They are here just to show you what the boxes are being used for.

There are some additional advanced features of class models.

For that I’d like to mention interfaces,parameterized classes,nested classes,composite objects.

If you are familiar with an object-oriented language like java,you know that you can express in your program a type by using the interface construct within java.

In the interface description you typically describe what that interface provides to the rest of the system and what it requires from the rest of the system.

Parameterized classes correspond to java generics or c++ templates.that is, they provide a way of, for example describing collection classes by giving a parameter that is a type of the class.

Example you have a set of vehicles,you have a set of bank accounts.

Thirdly,Nested classes,if you are familiar with java class definition,you can have other classes inside a class.

They are sometime called nested classes or inner classes.

Finally,you can have composite objects.These are objects that contain other objects within them.

In the OOA we saw that nouns could give us a good lead into what the classes are going to be.

Similarly,verbs can be used for several purposes one of which is to describe what the relationships are between classes.

In the UML there are three kinds of relationships,their association,example association between people and vehicule,people can drive vehicules.

There is generalization,that is a car kind of vehicule. And there is a dependencies.

Their might be dependency between cars and pollution laws.

If a pollution laws changes,car might have to be adapted.For example putting on some kind of pollution control device.

For Association,there are a lot of notation affordances:

Name
Association classes
Aggregation and composition
Generalization
Navigability
Multiplicity
Role names
Qualifier
Link
Constraints

Association class

You can think of it as an association that has some class properties or some association properties:

As you might see in the example above, that their is an other association for Job,it is a recursive association.

It is better to use role name for this kind of association.

Aggregation and Composition

This is about one class related to many other classes.

Aggregation doesn’t really say much about semantic of the relationships.in particular it doesn’t say much about the lifetimes of the participant objects.

For example,lets say you have a house class and room class.

Clearly a house has rooms so you would expect there to be an aggregation there.But,further if you destroy the house you also destroy the rooms.

Therefor instead of using aggregation, we would use composition.

In the composition, there is a responsibility of managing the lifetime of the constituent objects.

That further says, that a particular constituent can only belong to one composition.

Compositions, also have the transitive property.That is, a house can have room and room can have closets.

For aggregations there is no rules like this.Aggregations are general situations.

I might say, for example, that a room has a table.

Now,this is an aggregation situation,because we certainly destroy the room after we take the table out.

They don’t have the same lifetime. Therefore we’d use aggregation instead of composition.

Qualifiers

They are indicated with small rectangles, that are on the sides or edges of class rectangles.

The small rectangles contain the name of one the attributes, of that particular class.

The attribute within the small rectangle, is the qualifier, that can provide access to, instances of that particular class.

If you were doing a relational database model you would think of the qualifier as the key, into the set of the instances.

Links

Just like classes can have instances, associations can have links.

Example:

If we had the situation where a company hires people,we might have a situation Facebook hires Jack.Facebook hires Sara.Google hires Tom and Google hires Sara.

Sara has two jobs.In this situation we would have four different links.

Generalization

It is also indicated by a solid line, but in this case the line ends with a triangle.

The semantic is that all instances of the subclass are also instances of the parent class.That is a subset of relationship.

Generalization is not as Inheritance.Inheritance is an implementation technique,generalization is modeling approach.

In UML,generalization supports both multiple parent classes for a given class and multiple child classes.

You can specify discriminators. That is names of groups of subclasses.

Conclusion:

UML provides a rich vocabulary for modeling a system structure.and the UML class model diagram exibits many, many different features.

However,there is no need for you to use all of its affordances.

Particularly at start of modeling process.

Nevertheless,each affordance implies a question to be answered.

What is the multiplicity ?

Are these values ordered ?

What’s the qualifier ?

Does the system, that you are modeling, exibit the property expressed by that affordance ?

One of the important benefits of modeling ,is that it encourages you to face these questions early,in the development process.

Because,if you forget and they may later come back to haunt you.

As a bonus from this article, I want to share with you some books,that changed my life in the domain of software design engineering:

1- Clean Code: A Handbook of Agile Software Craftsmanship

2- Clean Architecture: A Craftsman’s Guide to Software Structure and Design (Robert C. Martin Series)

3-The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition

And you, what do you think about class diagram ?

How To Be a Great Problem-Solver Software Engineer

Before you can solve a problem,you need to understand it.The process of understanding a problem is called Analysis.

The most important analysis type is Object-Oriented Analysis (OOA).

OOA is a requirements analysis techniques developed by Abbot and Booch in the 1980s.

It concentrates on modeling the real-world objects based on their desicriptions in natural language to produce an object analysis model.

Structured analysis and design techniques are functionally oriented.

They concentrate on the computations that need to be made.the data upon which the functions operate are secondary to the functions themselves.

Object Oriented Analysis and design on the other hand is primarily concerned with the data objects.These are defined first in terms of their attributes and data types, and defined and associated with a specific objects.

First, it takes a textual description of system to be build, such as a requirements document. And looks for different kinds of words such as nouns, verbs, and objectives.

Nouns correspond to classes, actions verbs to operations. Adjectives to attributes and stative verbs to relationships.

The resulting class model can be reviewed with a customer for accuracy and completeness.

Here is an overview of the steps involved:

1- Candidate object classes are indicated by occurrence of nouns in the natural language description of the system to be build.

2- The nouns can then be organized into related groups termed classes.

3- The next step looks for adjectives, which often indicates properties that can be modeled as attributes.

4- Subsequently, action verbs can be modeled as operations and assigned to an appropriate provider class.

5- Other stative verbs are indicative of relationships among classes

Actually, the OOA techniques are the following:

1- Obtain and prepare textual description of the problem

2- Underline all the nouns

3- Organize the nouns into groups to become candidate classes

4- Underline all the adjectives

5- Assign the adjectives as attributes of the candidate classes

6- Underline the verbs, differentiating action from stative verbs

7- Assign action verbs as operations of classes

8- Assign stative verbs as attributes of classes or relationships

It sounds simple isn’t it ?

Here are some of the issues that arise when we try to accomplish the first step in OOA.

1- Some words are duplicated

2- Some words share the same stem

Some words are close to each other and really share the same underlying concept like leaf and leaves.

In these cases we are going to do what’s called stemming.

The stemming removes the prefixes and postfixes, the suffixes to the words, and just uses the root word as the corresponding candidate and class.

Conclusion

Like any analyses process, the conclusions that we reach are always tentative.as we engage in the process, we learn more about the problem, which my lead to revisions of our analysis.

In fact,it was one of the early lessons of software engineering, is that requirements documents are always wrong.

In the sense that they’re incomplete, or inconsistent, or they don’t truly reflect what it is that the customer ultimately wants. And as an analyst it’s our job to elicit that correct description.

Thanks for Reading !

If you like my work and like to support me …

Follow me on twitter here
Follow me on facebook here
Subscribe on my Youtube channel,I share lots of amazing content like this but in video

The Key to Becoming a Professional Software Engineer

The process of building a program while satisfying a problem’s functional requirements and not violating its non-functional constraints,is called the software design.

The design is the most creative part of the software development process.

It’s broken normally into two main parts,architecture design and detail design.

Architectural design

The process of identifying and assigning the responsibility for aspects of behavior to various modules or components of a software.

Detail design

It is about dealing with every particular component.

Also, it is the process of specifying the behavior of each of the system components that you have identified during the architectural design.

it includes data structures and algorithms.

One of the best statement I like the most about the software design,is the one from Wasserman:

“The primary activity during data design is to select logical representations of data objects identified during the requirements definition and specification phase.
The selection process may involve algorithmic analysis of alternative structures in order to determine the most efficient design or may simply involve the use of a set of modules that provide the operations upon some representation of an object.”

There are many approaches to software design,some intended for how best to structure a system, such as Object oriented design.

Some of them are intended for particular class of application.That is the design of real time systems.

Some of them are structured to deal with certain kind of application, such as user interface design.

All aspects to the design may include three aspects that may be compared, the design method, the design representation, and how that design is going to be validated.

Design method

A method is a systematic sequence of steps that a software engineer or designer uses to solve a problem.

It suggests a particular way of reviewing a problem.

The design representation

The representation is independent of the programming language used in software implementation and covers certain basic concepts of software design: control flow, data flow and data abstraction.

The design validation

It is the process of checking whether the specification captures the customer’s needs.

The bottom line is you can’t design a complex system without having some idea of what is supposed to do.

That’s why we use analysis Model,which is concerned with the problem being solved and design is concerned with the solution to that problem.

Diagram can help express that understanding and express your solution to that problem.

Conclusion:

UML(The Unified Modeling Language) provides a wealth of diagram types for you as well as OCL(Object Constraint Language) and meta model.

In general, the more precisely you understand the problem the fewer subsequent problems you will have with that system’s history.

Thanks for Reading !

If you like my work and like to support me …

Follow me on twitter here
Follow me on facebook here
Subscribe on my Youtube channel,I share lots of amazing content like this but in video